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

Fri Feb 15 23:02:15 UTC 2019

On Fri, 15 Feb 2019 18:33:30 +0100,
Lewis Rosenthal wrote:
> 
> 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:

Yes you may.  Quite frankly, I'm frustrated with the situation, and
it...  well, kinda exploded today (getting a huge bunch of messages
from mailman tell us that it had disabled this and that user, it
turned out to be quite a lot of them...).  Either way, I'll take any
help I can get to get some clarity and a path forward.

> 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.)

Well, if we change the subject of a DKIM signed message, don't we
break it?  (I'm not sure how applicable that's with Google, as we
received the same kind of bounce for message originating at
openssl.org (there is a DMARC record with p=none, so shouldn't affect
anything as far as I understand) and no DKIM signature...  but still,
when there is one...

> > 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.

Well, Google users is a *large* part of our subscribers, and some of
them are Google Apps users, possibly not of their own choice.  I
believe that Google users aren't quite as easy to dismiss as, say,
hotmail back when that provider tumbled down the reputation shute.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/