B4J Question Receiving e-mails with body = null and attachments.

[PierPaduan]

Hi,
I have a B4J app working as an e-mail server. I started from this:
https://www.b4x.com/android/forum/threads/building-a-mini-email-based-server.35030/#content

I send e-mails from a B4A app and from B4i app to the B4J e-mail server. I don't use attachments, only text in the message body.

If I send e-mails from B4i app (using iOS built in e-mail client) or from B4A app (using Gmail), the B4J app read correctly the information stored in the e-mails body.

If I send e-mails from B4A app using another e-mail client (not Gmail), the B4J app receive e-mails with body null, and 2 attachments.

- How can avoid this?
- May be the body as been moved in the attachments?
- How can I read the attachments?

Thanks a Lot to everybody.
Best regards.

 

[PierPaduan]

Update:

Thanks to MailParser work, I've discovered that the body has been moved in the attachments and I has been able to read the information inside.
I've fixed my problem, but I still don't know if it's possible to avoid that e-mail body became Null.

May someone answer to this question?

 

[OliverA]

it's possible to avoid that e-mail body became Null

Just a guess, but I think it is the e-mail client that is the issue, not your server. Your e-mail client may sent the mail as HTML and create a multi-part e-mail. Make sure the e-mail client is set to sent the e-mail as text only.

 

[nwhitfield]

Depending on where the message has come from, what appears to be the body may actually be an attachment, and possibly even base64 encoded. Some people do that to ensure that any special characters are sent without being corrupted. And though it's good practice to include an alternative encoding, it's not mandatory.

Messages where the Content-Type header is set to "multipart/alternative" will often appear to have no body, and the client is supposed to pick whichever of the content sections it is best able to display - typically that would be text/plain or text/html

However, as I mention, don't assume that the text/plain part will necessarily be human readable. Looking at a mailing list message I have in my inbox, both the html and text/plain parts have Content-Transfer-Encoding: base64 headers, designed to ensure nothing will be destroyed by any weird gateways.

You can try and tell people to only send in plain text, but many years experience of running mailing lists suggests to me you'll be fighting a losing battle.

An old saying when it comes to internet standards is "Be liberal in what you accept, and strict in what you send out" and it particularly applies to email. There's an astonishing number of really shit email clients out there that will generate all manner of junk for you to try and handle.

 

[PierPaduan]

Thanks for your answers.
I have no power about the decision of which email clients my customers can use.
So now my server will accept both e-mail with body and e-mails with attachments.