Email Forwarding Results in Spoofing and Bounce Back Emails

Question: Is there an option within virtualmin (or postfix) that will allow receiving parties to see that forwarded messages are coming from the virtualmin server rather than the original sender?

Observation:

Recently it appears that many of the large free email service providers have made adjustments to prevent email spoofing via SPF validation or other means which has introduced an interesting issue for one of our Virtualmin servers.

Issue Description:

Open Relay has been disabled on the server requiring clients to authenticate with their username and password to send messages. However when configuring email forwarding for a mailbox messages are forwarded to the recipient with a reply-to-address of the original sender rather than the forwarding mailbox. This is resulting in an email spoof which yahoo and gmail are now blocking.

Example:

@send.com --- this will be the original sender (outside) @forward.com --- this will be the mailbox forwarding messages on the virtualmin server (local) @receive.com --- this will be the final recipient of the forwarded message (outside)

@send.com composes and sends a message to @forward.com which is hosted on a virtualmin server. @forward then forwards this message to @receive.com.

You would think that all would be well as there is an spf record for all 3 domains allowing each to send from the appropriate mail provider. However this is resulting in a bounce back as the @receive.com address believes that the message came directly from @send.com resulting in a spoof.

Bounce Back:

----- Forwarded Message ----- From: Mail Delivery System MAILER-DAEMON@forward.com To: user@yahoo.com Sent: Wednesday, May 21, 2014 3:20 PM Subject: Undelivered Mail Returned to Sender

This is the mail system at host forward.com.

I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to

If you do so, please include this problem report. You can delete your own text from the attached returned message.

              The mail system

user@msn.com (expanded from user@forward.com): host mx4.hotmail.com[65.55.33.135] said: 550 5.7.0 (COL0-MC6-F23) Unfortunately, messages from (74.112.168.36) on behalf of (yahoo.com) could not be delivered due to domain owner policy restrictions. (in reply to end of DATA command)

Status: 
Active

Comments

Howdy -- yeah, email forwarding can make things a bit tricky when dealing with certain anti-spam methods.

In the case you're describing -- if I understand correctly, one thing we may want to verify is that the primary IP address of your server should be listed in the SPF record as an allowed sender. Is that true in your particular case?

If that's not helpful or applicable in your case -- it might help us to be able to talk about the actual domain names and IP addresses that are in use. We can set your request to private though so that no one outside of the Virtualmin staff will see it.

Just to add to this, forwarding is a bad idea. I explain to my clients exactly why forwarding is not recommended and strongly advise that they don't rely on forwarding. If they want to have two separate email addresses then they'll just have to check separate inboxes.

HOWEVER, since this approach may not be suitable for you then here is another approach you can take that has worked for me in the past.

If you have a client that insists on using your Virtualmin server as a forwarding server, then route all of his forwarded emails via an external service such as Mandrill. That will rewrite the mail headers completely so you should have no problem between @forward and @receive.

Setup Mandrill as described here : http://help.mandrill.com/entries/23060367-Can-I-configure-Postfix-to-sen...

And then tell Postfix to use Mandrill for any emails destined for your clients receiving email address.

# /etc/postfix/main.cf
transport_maps = hash:/etc/postfix/transport

# /etc/postfix/transport
user@receive.com smtp:[smtp.mandrillapp.com]

$ postmap /etc/postfix/transport

As I said above, the best solution is to advise your clients that forwarding is an outdated practice and isn't compatible with today's modern anti-spam / spoofing practices. If they insist on it then you can't be responsible for any failed deliveries on the second leg of the journey.