4 ms·

To implement this correctly, put your service's email address in the "Sender:" header (and also for the "mail from" when establishing the SMTP connection) to re

by biot 14y ago

To implement this correctly, put your service's email address in the "Sender:" header (and also for the "mail from" when establishing the SMTP connection) to remain SPF compliant while still keeping the user's email address in the "From:" header: http://www.openspf.org/Best_Practices/Webgenerated http://www.openspf.org/Best_Practices/Webgenerated Note that this will show up as "(user's info) on behalf of (your app's info)" or "(user's info) via (your app's info)" depending on the recipient's mail client.

pilif 14y ago
Unfortunately, in the most widely used Email client (Outlook), it will show up as "(your app's info) on behalf of (user's info)" So at a casual glance, the mail will still look as if it's coming from your app. Replies will go to your app's address too. While a good idea in theory, this behavior of Outlook kind of renders the Sender header useless.
- eloisant 14y ago
  The thing is if you don't do that, you risk being marked as spam because you obviously don't control the gmail.com or hotmail.com domain.
- LaGrange 14y ago
  No it doesn't. The information on who this is supposedly from is useful, but hiding the actual sender is potentially harmful.
guptaneil 14y ago
We're still using an @tabuleapp.com email address for the From header, just setting the from name to be the user's name. This way we don't violate SPF constraints, and we can accept replies to the notification emails.
- MicahWedemeyer 14y ago
  This is a good strategy. My only complaint with it (and I do it too for some things) is that it can mess up people's address books a little. For example, when I start typing someone's name in gmail, sometimes I get "Joe Smith <a3gfdf33sds32fs@someapp.com>" instead of "joesmith@hisdomain.com"
speleding 14y ago
That page suggests adding a "Sender" header. Up to now I've always used the "Resent-from" header for the purpose of complying with the SPF requirements (pretending to be a forwarding service). Do you now if there is an advantage of using one versus the other? Reading the RFC it looks like the "Sender" might be a bit more accurate in this context, but the Resent-From may look better in e-mail clients.

by biot 14y ago

pilif 14y ago

Unfortunately, in the most widely used Email client (Outlook), it will show up as "(your app's info) on behalf of (user's info)" So at a casual glance, the mail will still look as if it's coming from your app. Replies will go to your app's address too. While a good idea in theory, this behavior of Outlook kind of renders the Sender header useless.

eloisant 14y ago
The thing is if you don't do that, you risk being marked as spam because you obviously don't control the gmail.com or hotmail.com domain.
LaGrange 14y ago
No it doesn't. The information on who this is supposedly from is useful, but hiding the actual sender is potentially harmful.

guptaneil 14y ago

We're still using an @tabuleapp.com email address for the From header, just setting the from name to be the user's name. This way we don't violate SPF constraints, and we can accept replies to the notification emails.

MicahWedemeyer 14y ago
This is a good strategy. My only complaint with it (and I do it too for some things) is that it can mess up people's address books a little. For example, when I start typing someone's name in gmail, sometimes I get "Joe Smith <a3gfdf33sds32fs@someapp.com>" instead of "joesmith@hisdomain.com"

speleding 14y ago

That page suggests adding a "Sender" header. Up to now I've always used the "Resent-from" header for the purpose of complying with the SPF requirements (pretending to be a forwarding service). Do you now if there is an advantage of using one versus the other? Reading the RFC it looks like the "Sender" might be a bit more accurate in this context, but the Resent-From may look better in e-mail clients.