15

I wanted to know the best way to make my mailserver send emails on behalf of my clients' domains, without being greylisted and also avoiding bounce problems.

I've been reading some other questions here, here and here but none explores all the possible solutions. Here are some possibilities that I would like to compare:

A.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>  # mymailserver.com same IP as myapp.com
DATA
  From: <res@client.com>
  Sender: <do-not-reply@myapp.com>

Question: This is what gmail does. It's the msg header "From:" that has a different domain, not the envelope sender.
emailclients will show "From:res@client.com via do-not-reply@myapp.com" or "From:do-not-reply@myapp.com On Behalf Of res@client.com", which is not a problem for me.
Now, will this affect badly the reputation of my domain, the fact that the header "From:" has a different domain? (and if it's not Google who's doing it..)

B.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>
DATA
   From: <res@client.com>
   # same as A, but no "Sender:"

It looks like Google once did this and called it a mistake http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf+of%22&pli=1
A bug removed the "Sender:" from their messages and the "via" didn't show up in the emailclient. (The RFC says that it MUST be present if it's not the same as the "From:")

C. 

HELO mymailserver.com
MAIL FROM<res@client.com>
DATA 
  From: <res@client.com>

It's as if client.com were sending the message (the MAIL FROM is "spoofed" too). But if the client.com domain is well-known or has a SPF entry in its DNS, I would have to alter its DNS, allowing mymailserver.com to send message in their behalf.. (This is impossible for me because of the nb. of clients, and also some of my clients don't have control over their domains, i.e., are using @gmail.com themselves)

D.

HELO mymailserver.com    
MAIL FROM<do-not-reply@myapp.com>
DATA 
  From: <do-not-reply@myapp.com>
  Reply-to: <res@myclient.com>

Question: This is the simplest one, I would only add a "Reply-to:" header. Is this really taken into account ALL THE TIME by email clients? Can this be perceived as spoof too, adding different domains to the "Reply-to" header, and be a bad influence to my domain's reputation?
- The RFC only says that "if the Reply-To field exists, then the reply SHOULD go to the addresses indicated in that field and not to the address(es) indicated in the From field.".
- Only the "From:" header label would be "spoofed":
"From: myclient.com (via myapp.com) < do-not-reply@myapp.com> ".

Community
  • 1
dgaspar
  • 251
  • 1
  • 2
  • 4
  • When reading RFC's, 'SHOULD' means it's a very strong recommendation. The only reason a client wouldn't in most cases is because it's old and hasn't been updated since that RFC was written. See RFC 2119 for the standard definitions: http://www.ietf.org/rfc/rfc2119.txt – Matthew Scharley Sep 16 '11 at 10:39
  • possible duplicate of [Does sending e-mail in the name of customers increase the risk of being marked as spammer?](http://serverfault.com/questions/132113/does-sending-e-mail-in-the-name-of-customers-increase-the-risk-of-being-marked-as) – mailq Sep 17 '11 at 12:37
  • Unfortunately as of 2018 many e-mail clients still ignore the Reply-To header. https://meta.discourse.org/t/reply-keys-reply-email-addresses-not-always-used-mail-client-issues/38787 – Martin Meixger Feb 12 '18 at 08:37

3 Answers3

2

Excellent question. I've just spent several hours researching the same thing.

I had previously deployed numerous websites that use Option C for email forms (mainly out of naivety), but we are experiencing an increasing number of delivery issues. Email providers are gradually tightening up on things. For example Yahoo recently changed their DMARC policy to ask receivers to reject all emails From: ____@yahoo.com without a valid DKIM signature. Receiving SMTP servers that follow DMARC (which includes Gmail, and probably Hotmail/Outlook.com and Yahoo) will hard bounce these messages. eBay and Paypal have similar strict policies I believe, in an attempt to reduce phishing. Unfortunately specifying a "Sender" header does not help.

(I wonder how Gmail works around this when sending "From" a Yahoo alias?!)

Option A would be a better option if you know the "From" email does not have a strict DMARC policy (you could possibly confirm this via a simple DNS query).

Despite being the least visually-appealing, Option D is really the safest and is what I will recommend for most of our future projects. It's worth noting that PayPal previously used Option A, but have now switched to Option D.

To gain additional credibility and increased chance of delivery, I would look at implementing SPF and/or DKIM. These and other things are mentioned in Google's Bulk Sender Guidelines which I found helpful.

Community
  • 1
Simon East
  • 1,484
  • 1
  • 14
  • 18
1

I'm not sure what you want. There is no "safe" or "unsafe" way to do what you want.

I would always prefer D). Additionally I would add SPF records. But as I said this is not safer or unsafer than the others (whatever you mean with it).

The Reply-To header does not influence the reputation in any way. It only advices the client to use that address for replies (Duh, maybe this is where the name comes from?!). If the client follows this recommendation is not guaranteed.

mailq
  • 16,882
  • 2
  • 36
  • 66
  • By "safe" I mean minimize the chances of having my domain greylisted, mistakenly considered as a spoofer/spammer because of the solution I picked. Yes, if I go with D, I can consider adding a SPF entry to my domain and signing the messages using DKIM. – dgaspar Sep 17 '11 at 09:05
  • I've edited my question and tried to clarify it.. – dgaspar Sep 17 '11 at 11:16
  • @dgaspar Greylisting is envelope based. So your content (From:, Sender:, ...) is totally ignored. As everybody can write any mail address as sender, every sender address is considered spoofed. Except you sign your mails with SPF or DKIM. – mailq Sep 17 '11 at 12:33
0

Two reliable solutions:

  1. ask from the customers to add your mailserver in their SPF domain record
  2. ask the customers to give you an email account credentials (their mailserver IP,username,password) and use these inside your application to connect to their mailserver and send email (you actually create an email client inside your application).
RalfFriedl
  • 3,008
  • 4
  • 12
  • 17
nonlinearly
  • 1
  • 1