Incoming SMTP in the year 2017 and absence of DKIM

Thu Nov 30 20:32:48 UTC 2017

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20171130/43dee291/attachment.bin>