Feb 272017
 

Strictly speaking how some cloud services do mail wrong, but whilst it is not all, there are still quite a few that do which is why there are no names contained within this rant.

When you have some cloud-based service send email, it makes sense for the “From” header (i.e. what sensible normal people think of as the sender address) to contain the email address of the person using the cloud-based service.

Fair enough.

But if the real sender address or envelope sender address (which is contained within the SMTP transaction) comprises the email address of the person using the cloud-based service you may well run into problems. Many organisations publish an SPF record in their DNS to indicate what network addresses are approved for, and many mail servers check the envelope sender against the published authorised network addresses.

If the network address used by the cloud service provider does not match what is in the organisation’s SPF record then the recipient’s mail server is free to reject the mail. And they often do.

Now the most obvious “fix” for this is to add the cloud service provider’s network address to the organisation’s SPF record.

The only trouble with that is that it isn’t always possible. There are various limits to how long an SPF record can be so adding addresses to the SPF record recklessly is unwise, and a sensible DNS administrator will only add to the SPF record for important services. So if the cloud service is being evaluated or being used by something less important, or is being used for non-work related purposes, then it likely won’t meet the “important enough to get added to the SPF record” criteria.

So why not fix the source of the problem?

All that has to be done is to use a different address for the envelope sender, and you can even arrange things to send bounces back to the right place.

Set the envelope sender to something like “customer+${original email}@${cloud service address}” (obviously when replacing the ${original email} you will have to change the “@” sign to something reversible). All of a sudden you are no longer “forging” the envelope sender, and not tripping over anyone’s spam defences.

Process the bounces to “customer@${cloud service address}” and you can send the bounces to the right place.