nanog mailing list archives
Re: Incoming SMTP in the year 2017 and absence of DKIM
From: Grant Taylor via NANOG <nanog () nanog org>
Date: Thu, 30 Nov 2017 13:32:48 -0700
On 11/30/2017 11:30 AM, John Levine wrote:
If you look at the bounce handling in packages like sympa and mailman, they have lots of heuristics to try to figure out what bounces mean. They work OK but I agree they are far from perfect.
I never have. Further, I think I'd like to not go insane.I naively would expect that one would look for the most common bounce format (likely standard DSN), then the next most common, ... rinse, lather, repeat.
I'd bet that between three and eight formats in, you would have a VERY LARGE portion of bounces covered.
I would also configure MLMs to forward unknown bounces to the -owner. Hopefully the -owner would then feed (a sanitized copy of) the unknown bounce type the MLM maintainer(s) to improve said MLM.
It's a rathole, it doesn't scale, and it is not a bug that you can send mail to people who you don't already know.
I wasn't aware that DKIM-ATPS necessitated needing to know who you were going to send to.
I thought DKIM-ATPS was meant to allow a 3rd party that you contract to be an "Authorized Third (party) Sender" of email for your domain.
Though, that doesn't do anything for recipients forwarding to their new mailbox.
If identities were a magic bullet, we'd all be signing with S/MIME.
I am (and have been for years) a proponent of S/MIME. Though I don't think that it really does anything to help with this paradigm. Unless you are able to filter incoming messages with the intention that all incoming messages MUST be signed and reject (or otherwise filter) unsigned messages.
(I think we're still talking about how can an intermediate mail server be authorized to be part of the SMTP end-to-end mail delivery chain. Even if said intermediate mail server is downstream of the sender.)
-- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Current thread:
- Re: Incoming SMTP in the year 2017 and absence of DKIM, (continued)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Ken O'Driscoll (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Michael Thomas (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM valdis . kletnieks (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Grant Taylor via NANOG (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM John Levine (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Grant Taylor via NANOG (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM John Levine (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM William Herrin (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Grant Taylor via NANOG (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM John Levine (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Grant Taylor via NANOG (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM John Levine (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Grant Taylor via NANOG (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM John R. Levine (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Grant Taylor via NANOG (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Bjørn Mork (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Rich Kulawiec (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Steve Atkins (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Bjørn Mork (Dec 01)
- RE: Incoming SMTP in the year 2017 and absence of DKIM Keith Medcalf (Dec 01)
- Re: Incoming SMTP in the year 2017 and absence of DKIM Owen DeLong (Dec 01)