Just like applications show a README.txt after getting installed, some applications on Blackberry handheld sends an email to the email address configured on the device. This email contains useful information about the application and usually explains about the features of the application. Professional applications, like- myBoxTone Expert from BoxTone and Fixmo Tools from FixMo are some of the examples.
That’s a smart idea to get user’s attention instead of showing a dialog box and let them read the entire message at the time of application installation. Put an email in their Inbox so that the information is there and let they come back and read it whenever they want. I tried the same thing recently for my application and I was caught with a interesting problem.
While trying to send an email to the user’s configured email address, the FROM field attracts the attention. I wanted to set the From field to contains an address which is not the user’s email address (i.e. something like “<Your Product Name> Support” <support@your_domain.com>). I was successfully able to set this value in the message FROM header of the message I created (using Message.setFrom() ), but when the email was sent (and received after a network roundtrip) the email’s from field still shows the original sender’s email address (i.e. the user’s email account configured on the device).
After a few of attempts with trial & error using different methods, I observed that Overriding the ‘FROM’ field in an email sent from Blackberry handheld, was something neither documented nor tried by anyone (as concluded after Googling for an hour). I tried various combination of Header settings with FROM and REPLY_TO headers to achieve this. Finally, I opened a thread on Blackberry Support Forums to ask if someone knows how to do it, but no luck. After much investigation on this, there appeared no clear way to achieve this. But then how the cool guys at BoxTone or Fixmo, did it in myBoxTone Expert or Fixmo Tools?
After much investigation on this, it turned out that this is a security feature in Blackberry OS, that doesn’t allow forging of FROM field in an email. The Blackberry OS doesn’t allow the message sender to change the FROM field in emails that are sent via the device. Hence, technically nothing at device side can be done for this. After thinking much on this side, there was a hack that I tried and was successful. Instead of creating and sending the email message, why not to save it in the Inbox and let it appear similar as if it was a received email?
Here is what I tried and the results were nearly similar. Read on for complete details:
Summary & Steps
It is true that blackberry doesn’t allow us to send an email with forged FROM field. But if we don’t send the email and simply save the message in INBOX, then that’s not a problem.
So the hack is to -
- Create an email message.
- Set the flag to Inbound (setInbound).
- Set the status to received (Message.Status.RX_RECEIVED).
- Save the message to Inbox folder
|public void createInboxMessage()
Store store = Session.getDefaultInstance().getStore() ;
Folder InboxFolder = store.list(Folder.INBOX); Message msg = new Message(InboxFolder) ;
Address replyTo = new Address ;
replyTo = new Address(“<no_reply>@Simulated_Senders_Domain.com“, “Invalid Receiver”) ;
// This is the Value BlackBerry doesn’t allow you
// You will still see this email in your Inbox
// Set Contents …
// Step No. 2 as in Summary & Steps
// Step No. 3 as in Summary & Steps
Step 2 changes the icon from that of ‘draft’ to that of an incoming message. Step 3 causes the messaging system to make it appear bold and unopened.
1. The message save will not be seen if the user open Outlook Web Access (OWA), since it is only in the INBOX folder of the device.
2. The system doesn’t flash LED as it happens when a new message arrives.
3. The short keys “R” (Reply) and “L” (Reply All) doesn’t work. This is probably because the message was not really received, it was only saved in the INBOX and it only look like received.
The approach of saving the message in Inbox instead of actually sending and then receiving after a network round trip, looks very useful since the effect is same to the user. This also make sense because if you ultimately want to show the email to user, then why to let they pay for carrier’s data charges (may be on roaming also). In all this approach looks promising to me and I will be using in my next Blackberry application. Additional, approaches or suggestions are welcome