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

Richard Levitte levitte at
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>: host[] 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
> > 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 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 (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: <>
> > 
> 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.


Richard Levitte         levitte at
OpenSSL Project

More information about the openssl-users mailing list