openssl-users: DKIM, DMARC and all that jazz, and what it means to us

[Lewis Rosenthal]

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 at example.com>: 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
-------------------------------------------------------------