Because Drupal sets the Reply-Path
the same as the From
header, receiving mail servers may think Drupal-generated email is spam if the domain in the Reply-Path
header doesn’t match the domain of the originating email server (which, for Drupal, is usually an smtp process on a webserver.)
Example: when I use the Contact module on the drupal.org website to send messages to anyone, the SPF records on my albin.net domain specify a list of valid originating email servers and can cause the messages sent from drupal.org to be flagged as spam (since drupal.org is not in my SPF record.)
Since this can cause all Drupal-generated to be thrown in the spam/trash bin, I feel this is a critical bug. Please feel free to downgrade it if I’ve overstepped my bounds.
The SPF website has a best practices for web-generated email page, which I followed to make this patch.
(This patch is actually against 5.1, but should apply to 6.x; I fear the bite of hackfest.)
Comment | File | Size | Author |
---|---|---|---|
#21 | user.module_68.patch | 6.53 KB | owahab |
#17 | spf_2.patch | 2.29 KB | JohnAlbin |
#14 | missing_semi1981.patch | 698 bytes | pwolanin |
#12 | spf_1.patch | 2.21 KB | JohnAlbin |
#9 | spf_0.patch | 1.13 KB | JohnAlbin |
Comments
Comment #1
Dries CreditAttribution: Dries commentedI think you're right. A lot of my contact-form mail ends up in my spam filter, and I already suspected this to be the case.
Patch looks good, but can you be a bit more verbose in the code comment? What exactly do you mean by "See RFC 2822 Sec 3.6.2 regarding Sender."? The code comment isn't very explanatory. It would be great if we could embed a bit more background information in the code comments (if only to avoid this bug from being re-introduced). We don't have to overdo it -- just enough information for people to understand why we do things this way.
Thanks John.
Comment #2
JohnAlbinThis patch has an explanatory comment.
Comment #3
Zen CreditAttribution: Zen commentedJohn,
6-dev is stable enough at the moment.
Review:
if (variable_get('site_mail', ini_get('sendmail_from'))) {
: This looks dodgy as an if clause. Moreover, this would cause errors when the site e-mail address is not specified (it is not, at present, a required field. But, it probably should be). The if clause can very likely just be discarded and the defaults merged with the array declaration above.I will update the patch later tonight if I'm not beaten to it.
-K
Comment #4
JohnAlbinThe if clause may be dodgy, but I was specifically trying to re-use code already in Drupal. This is a tricky issue because the only way to get the correct values is to ask for them from the user. But the user may put their own email address and not know what the correct values are because they are dependent on the webserver’s SMTP service (which may not even be the same domain as the website.)
Perhaps we should have two email fields: one for website contact email (which is what the current field is mostly used for) and one for web server email.
What we really need is a wizard for “web server email.” Something like:
There’s a bit of work with that idea, of course.
Comment #5
sepeck CreditAttribution: sepeck commentedJust to mention, rfc2821 supersedes rfc821.
http://www.faqs.org/rfcs/rfc2821.html
Section 4.4 covers some return-path usage and contains a note regarding rfc821's coverage. Not entirely sure of it would affect anything just thought I would point it out. I will try to do some more checking on it later.
Comment #6
Zen CreditAttribution: Zen commentedI've forked the default e-mail address issue to http://drupal.org/node/135320
I've re-rolled this patch assuming that the default address exists and is valid.
-K
Comment #7
JohnAlbinsepeck is correct. This patch needs to be rewritten taking RFC 2821 into account.
Comment #8
Zen CreditAttribution: Zen commentedIsn't that rather arbitrary, John? Please either show that something is wrong or post a patch fixing an issue where something will fail.
-K
Comment #9
JohnAlbinSorry, Karthik. I could have been more specific. The patch specifically mentions RFC 821, but it has been obsoleted by RFC 2821.
Some points to note:
site_mail
field is designed (and described as) a valid email for the website, i.e. the default From address. However, that email address is NOT the email that should be used for the Sender header. The Sender header should be the ACTUAL sender, i.e. the email address of the web/php server (often www@example.com.)Errors-To
header is non-standard and discouraged by many.So the solution to the problem would involve setting the
Sender</code, <code>Errors-To
, andReturn-Path
headers with the email address of the web/php process (and NOT with the$from
value.)Since there is no easy way to determine the “email address of the web/php process,” this new patch uses
site_mail
.Comment #10
JohnAlbinAccidently set wrong Status message.
Comment #11
Dries CreditAttribution: Dries commentedI think this patch looks good.
If your site (and mailserver) is example.com and if you set your e-mail address to be root@foo.com -- then you might get into trouble with spam filters? If so, I really think we need to add some _accessible_ guideline to the form description of the 'site e-mail' description. See http://drupal.org/node/135320. It seems like even with this patch, there still is a bit of a documentation work to be done, otherwise users might still be doing the wrong thing? Or am I confused now.
Either way, feel free to mark this RTBC.
Comment #12
JohnAlbinMerged this patch with the one at http://drupal.org/node/135320
The only change is an expanded description of the
site_mail
setting.Comment #13
Dries CreditAttribution: Dries commentedI've committed this to CVS HEAD. We'll want to backport this to DRUPAL-5 so I'm changing the version number.
Thanks for your persistence, John! Good job.
Comment #14
pwolanin CreditAttribution: pwolanin commentedThere was bad code in the commit:
A ";" is missing (see patch).
Comment #15
JohnAlbinOh, geez. Sorry guys. Thanks for catching that, Peter!
Comment #16
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. It might be helpful to roll a new patch for DRUPAL-5.
Comment #17
JohnAlbinNew patch re-rolled for DRUPAL-5. Without the parse error.
Comment #18
drummCommitted to 5.
There is a small code style issue- the double spaces between sentences should be single.
Comment #19
Dries CreditAttribution: Dries commentedI've ugraded my site to use this patch but the problem persists. All my contact form messages are marked as spam by Gmail. Odd.
Comment #20
sepeck CreditAttribution: sepeck commentedDries, If you could forward me the message header information from 2-3 messages I could look to see if there might be any other factors involved.
Comment #21
owahab CreditAttribution: owahab commentedPorting to 4.7
Comment #22
owahab CreditAttribution: owahab commentedComment #23
Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commentedcommitted.
Comment #24
(not verified) CreditAttribution: commentedComment #25
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedI had to revert the patch on the 4.7 branch
http://drupal.org/node/165732
Comment #26
mnur CreditAttribution: mnur commentedI am new to Drupal. I have problem with invite module. The email generated by my website goes directly to spam folder. I found out this went one of my friend said that my email from Drupal site goes to their spam folder. This case happened only went I send the email to Yahoo, however for Gmail, it is not categorize as a spam mail. Now I am using invite module 6.x-2.0-alpha1 and latest version of Drupal 6.13. What should do? I have read the solution for invite module version 5, however I am not sure where should I paste the patch if it valid for invite module 6 or Drupal 6.13. Thank you for your help?
Comment #27
Daniel Norton CreditAttribution: Daniel Norton commentedSite mail can also get a higher spam score if the "From" field does not have a display name. This patch for D7 addresses that issue:
Comment #28
dddave CreditAttribution: dddave commentedThis issue won't move until any solution is backported from the issue Daniel linked to (or from the issue which caused Daniel's to be classified as duplicate).
Comment #29
Damien Tournoud CreditAttribution: Damien Tournoud commentedPlease do not reopen old issues. This one is about adding technical headers to emails, and is long fixed.
Comment #30
sivahari CreditAttribution: sivahari commentedI am using webform module. The Email sent from the module semms SPAM. How can i resolve the problem.
--Sivahari