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
smime.p7s
Description: S/MIME Cryptographic Signature
