Mailman + Exim + strange headers

Hi there,
I've recently set up Mailman on my server, which runs Exim as the MTA (Debian). Things worked almost like a charm, except for one little detail: the messages' headers seem a little strange to me. Take a look at this example:
--8<---------------cut here---------------start------------->8--- Received: from localhost ([::1] helo=host.bla) by host.bla with esmtp (Exim 4.80) (envelope-from <list-bounces@list.bla>) id 1Wm4qV-0004Xb-2z; Sun, 18 May 2014 14:25:59 -0300 Received: from smtp.ble ([ANY.IP]) by host.bla with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <user@ble>) id 1Wm4qU-0004XV-9S for list@list.bla; Sun, 18 May 2014 14:25:58 -0300 Received: from [ANY.IP] (helo=localhost) by smtp.ble with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.62) (envelope-from <user@ble>) id 1Wm4qO-0005mm-GQ for list@list.bla; Sun, 18 May 2014 14:25:52 -0300
[...]
References: <ref1> <ref2> <ref3>
[...] --8<---------------cut here---------------end--------------->8---
As you can see, the first two "Received:" headers got messed up somehow, and the lines are not being prefix by \t but by one single space char. The same thing happens with the "References:", and all the other headers below.
After some investigation (and lots of email back and forth), I decided it is not Exim's fault, because it doesn't happen on situations when I use Exim without Mailman, so maybe it is Mailman or some weird scenario of Mailman + Exim modifying the e-mails without permission.
I am using Debian Wheezy (7.1), with Exim 4.80-7 and Mailman 2.1.15-1. I can provide my configuration files for Mailman and Exim, but basically what I did was to follow <http://www.exim.org/howto/mailman21.html>.
Any help is appreciated. Thanks,
-- Sergio

Sergio Durigan Junior writes:
As you can see, the first two "Received:" headers got messed up somehow,
I don't understand what you mean by "messed up". They looked perfectly readable and RFC-conforming to me.
and the lines are not being prefix by \t but by one single space char.
This is the RFC 5322 recommendation for folding header fields (use a space, not a tab).
use Exim without Mailman, so maybe it is Mailman or some weird scenario of Mailman + Exim modifying the e-mails without permission.
Older versions of Mailman (I'm not sure how old) are known to sometimes modify the headers by unfolding them and then refolding them when reassembling the message. This may still be true of the most recent versions. I believe this is considered a bug but hard to fix, and probably not worth fixing for that reason. Is this actually causing problems, or is it just ugly?

On Monday, May 19 2014, Stephen J. Turnbull wrote:
Thanks for pointing the RFC. I had the impression that, a while ago, I read an RFC explicitly mentioning that it should be a \t, not a space. Probably a thinko.
I am not exactly sure, but I wanted to try "fixing" this and see if things got better. The real problem is Google/Gmail tagging the mailing list messages as Spam, but since the headers are fine, the cause must be something else.
Thank you,
-- Sergio

On 05/19/2014 09:56 AM, Sergio Durigan Junior wrote:
My experience is that goggle sometimes will stop tagging emails as spam if they have a valid dkim signature. This probably means either:
- rewriting the from to be your local mailman server and signing the outbound message with dkim OR
- passing through any valid DKIM signature, which means running a recent version of mailman and avoid adding any headers/footers which would break the signature. OR
- possibly having no DKIM signature at all (better than having a signature which fails verification)
If there is a dkim signature and it fails google will treat it as spam
Goggle and the other various FREEMAILs maintain a rating of the credibility of email coming from your mailserver. DKIM signing (with a signature that will verify correctly) will increase your rating.
I was getting messages like the following from gmail and they stopped when I implemented DKIM signatures (must be a keysize of at least 1024):
Jan 21 16:36:06 myserv postfix/smtp[5374]: 68972108248: host gmail-smtp-in.l.google.com[74.125.142.26] said: 421-4.7.0 [1.2.3.4] Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 blocked. Please visit http://www.google.com/mail/help/bulk_mail.html 421 4.7.0 to review our Bulk Email Senders Guidelines. ih5si10430009icb.36 - gsmtp (in reply to end of DATA command)
You may also benefit from using DMARC (probably not technically, but politically).
You may not be doing bulk mailings, but the information here may be helpful: https://support.google.com/mail/answer/81126
Also you can try things like https://duckduckgo.com/?q=gmail+flags+my+mail+as+spam&t=canonical <https://duckduckgo.com/?q=gmail+flags+my+mail+as+spam&t=canonical> Also check http://multirbl.valli.org/ to make sure your mail server is not on any DNS blocklists.
Nataraj

Natu writes:
If there is a dkim signature and it fails google will treat it as spam
Note that, taking your words literally, this is against the DKIM RFCs -- a failed signature is supposed to be treated the same as a lack of a signature.
That doesn't mean that Google can't or doesn't use it. In particular, if the percentage of spam in the "failed or no signature" class goes up (which it will if you start signing), your "failed or no signature" rating will slump. That effect might be enough to send unsigned mail from your site to the spambucket.
But you can be sure that a valid DKIM signature will improve your site's reputation.

On 05/20/2014 05:17 AM, Stephen J. Turnbull wrote:
I believe you are correct Stephen. When I had the problem, in addition to signing outbound messages, I also increased the level of spam control. In particular I have a small number of users that forward their mail to gmail, and gmail was blocking us because of the spam that was getting forwarded. I suspect that it may only have effected the forwarded email from those accounts. I also made efforts to increase spam detected and thus reduced the amount of forwarded spam.
With Yahoo, I was also getting complaints that I was sending them spam (i.e. rejected mail from their smtp server). I registered with yahoo's complaint feedback loop, where they claim they will forward to you (the registered Mail administrator for the domain) any email they receive from your domain that they think is spam or that their users have flagged as spam. After I both turned on dkim and registered, I never got a single complaint from them. Note that we do NOT send any kind of marketing mail from this mailserver.
One other thing that might cause problems with the freemail providers is
as follows: If mailman sends a large number of messages to a freemail
provider that are almost the same, i.e. the exact same email, but
addressed to many different recipient, then they might think your are
sending bulk unsolicited mail. Having your mailing list mail test
positive in DCC is probably a good indication that this is happening.
There may be an option in mailman to ensure that outbound messages from
a single post don't all look identical. If so, you could try turning
that on.
Also, if you are dealing with lists that send high volumes of email to gmail, destination specific metering of your outbound mail, as well as adjusting the number of recipients in a single smtp transmission may help. If you are running postfix, discussions about how to implement this can be found in the postfix archives.
Nataraj

On 05/20/2014 09:25 AM, Natu wrote:
I would check your MTA logs and determine if you are experiencing any kind of throttling or rejection of mailing list mail sent to valid email addresses or if the only problem is that the messages are being put in the users spam or bulk folder.
Nataraj

Natu writes:
It sometimes happens that there is a way past a host's inbound filters. This shouldn't happen, of course, so when running mailing lists you want to filter on the way in.
But it might be an "amusing" test to hook up the spam checker to the *outgoing* MTA -- if it catches anything on the way out, then you have a backdoor into your MTA somewhere. For example, I trusted my secondary MXes to filter (in fact the evidence suggests their filtering was better than mine), until one day the spamchecker at one of them fell over, and they continued to forward mail addressed to us -- *including* the spam.
I happened to be online when it happened, or shortly after, so only a few hundred (!) got through, mostly to invalid addresses (thank heavens for really stupid spammers! at least that time :-). It turned out that *for me* there was no degradation of service when I stopped whitelisting that MX, and I ended up just checking *all* mail always regardless of my trust in the MX. But YMMV, be careful -- spam checking is resource intensive!
Also, if you're an ESP and your users keep their addressbooks on Windows machines, you probably should be filtering outbound anyway. In that case it's probably a good idea to keep your lists on a separate IP from your other users, which allows you to filter only on the way in (much more efficient).
Cool! Nice to hear that actually works (we've heard complaints here about Yahoo!s responsiveness in the past).
The option is "personalization". Many lists use it so the user gets a direct URL to their personal config page in the footer.
For the big ESPs like Yahoo!, just registering with their feedback loop or bulk mailer list often helps here, too. It may be worth experimenting with that, because turning on personalization may be a serious resource drain if you have hundreds of subscribers at one domain.
All good advice! Thank you for an excellent summary!
Steve

On 05/19/2014 07:43 AM, Stephen J. Turnbull wrote:
It is still true for current Mailman 2.1.x.
As of 2.1.13, Mailman no longer re-folds headers in message sub-parts in order to fix <https://bugs.launchpad.net/mailman/+bug/265967>, but the outer message headers may still be re-folded to conform to RFC length recommendations.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Sergio Durigan Junior writes:
As you can see, the first two "Received:" headers got messed up somehow,
I don't understand what you mean by "messed up". They looked perfectly readable and RFC-conforming to me.
and the lines are not being prefix by \t but by one single space char.
This is the RFC 5322 recommendation for folding header fields (use a space, not a tab).
use Exim without Mailman, so maybe it is Mailman or some weird scenario of Mailman + Exim modifying the e-mails without permission.
Older versions of Mailman (I'm not sure how old) are known to sometimes modify the headers by unfolding them and then refolding them when reassembling the message. This may still be true of the most recent versions. I believe this is considered a bug but hard to fix, and probably not worth fixing for that reason. Is this actually causing problems, or is it just ugly?

On Monday, May 19 2014, Stephen J. Turnbull wrote:
Thanks for pointing the RFC. I had the impression that, a while ago, I read an RFC explicitly mentioning that it should be a \t, not a space. Probably a thinko.
I am not exactly sure, but I wanted to try "fixing" this and see if things got better. The real problem is Google/Gmail tagging the mailing list messages as Spam, but since the headers are fine, the cause must be something else.
Thank you,
-- Sergio

On 05/19/2014 09:56 AM, Sergio Durigan Junior wrote:
My experience is that goggle sometimes will stop tagging emails as spam if they have a valid dkim signature. This probably means either:
- rewriting the from to be your local mailman server and signing the outbound message with dkim OR
- passing through any valid DKIM signature, which means running a recent version of mailman and avoid adding any headers/footers which would break the signature. OR
- possibly having no DKIM signature at all (better than having a signature which fails verification)
If there is a dkim signature and it fails google will treat it as spam
Goggle and the other various FREEMAILs maintain a rating of the credibility of email coming from your mailserver. DKIM signing (with a signature that will verify correctly) will increase your rating.
I was getting messages like the following from gmail and they stopped when I implemented DKIM signatures (must be a keysize of at least 1024):
Jan 21 16:36:06 myserv postfix/smtp[5374]: 68972108248: host gmail-smtp-in.l.google.com[74.125.142.26] said: 421-4.7.0 [1.2.3.4] Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 blocked. Please visit http://www.google.com/mail/help/bulk_mail.html 421 4.7.0 to review our Bulk Email Senders Guidelines. ih5si10430009icb.36 - gsmtp (in reply to end of DATA command)
You may also benefit from using DMARC (probably not technically, but politically).
You may not be doing bulk mailings, but the information here may be helpful: https://support.google.com/mail/answer/81126
Also you can try things like https://duckduckgo.com/?q=gmail+flags+my+mail+as+spam&t=canonical <https://duckduckgo.com/?q=gmail+flags+my+mail+as+spam&t=canonical> Also check http://multirbl.valli.org/ to make sure your mail server is not on any DNS blocklists.
Nataraj

Natu writes:
If there is a dkim signature and it fails google will treat it as spam
Note that, taking your words literally, this is against the DKIM RFCs -- a failed signature is supposed to be treated the same as a lack of a signature.
That doesn't mean that Google can't or doesn't use it. In particular, if the percentage of spam in the "failed or no signature" class goes up (which it will if you start signing), your "failed or no signature" rating will slump. That effect might be enough to send unsigned mail from your site to the spambucket.
But you can be sure that a valid DKIM signature will improve your site's reputation.

On 05/20/2014 05:17 AM, Stephen J. Turnbull wrote:
I believe you are correct Stephen. When I had the problem, in addition to signing outbound messages, I also increased the level of spam control. In particular I have a small number of users that forward their mail to gmail, and gmail was blocking us because of the spam that was getting forwarded. I suspect that it may only have effected the forwarded email from those accounts. I also made efforts to increase spam detected and thus reduced the amount of forwarded spam.
With Yahoo, I was also getting complaints that I was sending them spam (i.e. rejected mail from their smtp server). I registered with yahoo's complaint feedback loop, where they claim they will forward to you (the registered Mail administrator for the domain) any email they receive from your domain that they think is spam or that their users have flagged as spam. After I both turned on dkim and registered, I never got a single complaint from them. Note that we do NOT send any kind of marketing mail from this mailserver.
One other thing that might cause problems with the freemail providers is
as follows: If mailman sends a large number of messages to a freemail
provider that are almost the same, i.e. the exact same email, but
addressed to many different recipient, then they might think your are
sending bulk unsolicited mail. Having your mailing list mail test
positive in DCC is probably a good indication that this is happening.
There may be an option in mailman to ensure that outbound messages from
a single post don't all look identical. If so, you could try turning
that on.
Also, if you are dealing with lists that send high volumes of email to gmail, destination specific metering of your outbound mail, as well as adjusting the number of recipients in a single smtp transmission may help. If you are running postfix, discussions about how to implement this can be found in the postfix archives.
Nataraj

On 05/20/2014 09:25 AM, Natu wrote:
I would check your MTA logs and determine if you are experiencing any kind of throttling or rejection of mailing list mail sent to valid email addresses or if the only problem is that the messages are being put in the users spam or bulk folder.
Nataraj

Natu writes:
It sometimes happens that there is a way past a host's inbound filters. This shouldn't happen, of course, so when running mailing lists you want to filter on the way in.
But it might be an "amusing" test to hook up the spam checker to the *outgoing* MTA -- if it catches anything on the way out, then you have a backdoor into your MTA somewhere. For example, I trusted my secondary MXes to filter (in fact the evidence suggests their filtering was better than mine), until one day the spamchecker at one of them fell over, and they continued to forward mail addressed to us -- *including* the spam.
I happened to be online when it happened, or shortly after, so only a few hundred (!) got through, mostly to invalid addresses (thank heavens for really stupid spammers! at least that time :-). It turned out that *for me* there was no degradation of service when I stopped whitelisting that MX, and I ended up just checking *all* mail always regardless of my trust in the MX. But YMMV, be careful -- spam checking is resource intensive!
Also, if you're an ESP and your users keep their addressbooks on Windows machines, you probably should be filtering outbound anyway. In that case it's probably a good idea to keep your lists on a separate IP from your other users, which allows you to filter only on the way in (much more efficient).
Cool! Nice to hear that actually works (we've heard complaints here about Yahoo!s responsiveness in the past).
The option is "personalization". Many lists use it so the user gets a direct URL to their personal config page in the footer.
For the big ESPs like Yahoo!, just registering with their feedback loop or bulk mailer list often helps here, too. It may be worth experimenting with that, because turning on personalization may be a serious resource drain if you have hundreds of subscribers at one domain.
All good advice! Thank you for an excellent summary!
Steve

On 05/19/2014 07:43 AM, Stephen J. Turnbull wrote:
It is still true for current Mailman 2.1.x.
As of 2.1.13, Mailman no longer re-folds headers in message sub-parts in order to fix <https://bugs.launchpad.net/mailman/+bug/265967>, but the outer message headers may still be re-folded to conform to RFC length recommendations.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (5)
-
Mark Sapiro
-
Nataraj
-
Natu
-
Sergio Durigan Junior
-
Stephen J. Turnbull