Hi, Richard...
I'm not going to place my reply after Jakob's, as his makes a number of
excellent points, with many of which I wholeheartedly agree (I'm not big
on DKIM and DMARC, myself). However, a few points specific to the case
at hand, if I may:
Richard Levitte wrote:
Hi all,
It seem like DMARC, SPF, DKIM, or *something* is tripping us up quite
a bit. Earlier this afternoon (that's what it is in Sweden at least),
us postmasters got a deluge of bounce reports from mailman, basically
telling us that it got something like this:
<user@xxxxxxxxxxx>: host aspmx.l.google.com[74.125.140.26] said:
550-5.7.1 This message does not have authentication information or fails to
pass 550-5.7.1 authentication checks. To best protect our users from spam,
the 550-5.7.1 message has been blocked. Please visit 550-5.7.1
https://support.google.com/mail/answer/81126#authentication for more 550
5.7.1 information. f1si3266960wro.105 - gsmtp (in reply to end of DATA
command)
There's very little fact of what actually triggered these bounces, but
they always come from Google, so we're guessing that they're becoming
increasingly aggressive in their checks of DKIM, SPF, ARC, who knows
(they don't seem to check DMARC, 'cause we do have one with p=none and
an address to sent DMARC reports to, and I'm hearing absolutely
nothing from Google, but I do hear from others)
The onus for getting the attention of the mail admins at Google needs to
be on those who use their services for mail, and not on a third party.
If this were a non-technical list (the high school soccer team
schedule), I might not expect all of the list members to be able to
discuss in technical terms with the Google mail admins what the problems
may be, but people on this list should be able to get the relevant
points across, citing RFC numbers and so forth.
I often find myself assisting other admins (aren't we all on alternating
sides of that coin?) when we have delivery problems. The biggest hurdle
is getting to the right admin on the "problem" side, which is why the
initial contact needs to come from one of their customers who has been
affected.
So, to mitigate the problem, we've removed all extra decoration of the
messages, i.e. the list footer that's usually added and the subject
tag that indicates what list this is (I added the "openssl-users:"
that you see manually).
I strongly encourage you to re-think this. Everyone else on this list
whose server has been properly configured to not trash legitimate
messages must now be inconvenienced by the needs of a seemingly
tone-deaf provider. (FWIW, I go through this with yahoo.com addresses
all the time; the fault lies there, not in the list configuration - so
long as the list configuration follows the applicable RFC guidelines.)
So IF you're filtering the messages to get list messages in a
different folder, based on the subject line, you will unfortunately
have to change it. If I may suggest something, it's to look at this:
List-Id: <openssl-users.openssl.org>
Yes, this can be done, but without the list ID in square brackets in the
subject, what is liable to happen is that the entire string will be
replaced along the line when thread subjects change (e.g., "blah-blah
(was: blah)") and we would all have to remember to type "openssl-users:"
in order to get "organized" subjects (yes, I know; filtering to a
particular folder on the List-Id header should effectively "organize"
list messages by corralling them, but that's not my point). Threading is
liable to go at least slightly off the rails for some of us (depending
upon mail client), and there are a host of potential side effects, all
for what? The next time Google decides to change their filters, should
list managers hop-to and make further changes?
My own thinking is that if list messages cannot proliferate across
Google's infrastructure, then those list members should find alternative
means of subscribing. Undoubtedly, this is not the only list which would
be so affected for them.
--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA
Rosenthal & Rosenthal, LLC www.2rosenthals.com
visit my IT blog www.2rosenthals.net/wordpress
-------------------------------------------------------------
