Thanks for your reply.
On Tuesday, October 20, 2020 3:24 AM, John Levine <johnl(_at_)taugh(_dot_)com>
[ Replies sent to ietf-822 since this is unrelated to DMARC ]
(Sorry, I wasn't sure where to send this e-mail to.)
I've submitted a draft for a new Authentication-Results method a while
back 1. I'd like to get some feedback.
My use-case is: on a mailing list system 2, I'd like to display PGP
signature status, if a PGP signature is present. ...
Does this sounds like something worth doing?
Maybe, but probably not.
DKIM is intended as a signature for messages in transit, applied as a
message leaves its sending system and verified as it arrives at the
recipient system. The sorts of changs made by list managers often
break DKIM signatures, causing all sorts of excitement when DMARC
PGP signatures (and S/MIME signatures) are normally applied and
verified by the end-user mail programs. They're in the message body
and the changes that list managers typically make, tagging the
signature or adding body headers or footers, are unlikely to break a
I can think of ways a ML can change a PGP-signed message to make it
invalid. Adding a footer to all inline text parts for instance.
Or to put it another way, if your A-R header said the PGP signature on
the message contents was good, but the end user found it was bad, that
would suggest something was screwed up, not normal mailing list
I don't think I understand your point here.
I don't expect the A-R header of the mailing list server which relayed
the message to be preserved. In fact, many mail filters adding A-R will
just remove all existing A-R header fields.
In an email client, I may want to display the DKIM A-R result in the
UI. A bad DKIM signature might indicate an untrustworthy message.
Similarly, I may want to display the PGP signature verification result.
PS: It's not unreasonble for a list manager to use a PGP signature to
verify that it should forward a message, but there's not much use to
adding a header saying it did so.
(My goal isn't to necessarily block messages with a bad PGP signature,
but rather display the PGP verification result in the mailing list
Well, what's the use-case for A-R then? Couldn't the receiving server
check DKIM/DMARC without adding an A-R field and drop/quarantine
messages which fail this test?
My understanding was that A-R allows to have standardized email filters
that check DKIM/DMARC, put the result in a header field, and then
system administrators can consume this field and decide what to do. I
think this could apply to PGP as well.
I don't want to perform PGP key lookup and verification in the Web
server displaying the ML archives. I'd rather do this upon receiving
the message, in a completely isolated daemon (just like DKIM, e.g. with
ietf-822 mailing list