From: Brad Templeton <brad(_at_)templetons(_dot_)com>
...
This could be done with an authenticated errors-to header which provides
a common, authenticated point for all bounces to be sent to and collected,
...
And of course, old MTAs will not send errors to the address, so you must
handle both, but slowly the volume would move to the consolidated format.
You still need bounces on individual mail, but you can eventually insist
that high volume mail use the high volume error reporting system.
Assume for the safe of argument without agreeing that the current
bounce scheme needs to be fixed (because I don't). I'd rather delay
the effort to write and install future software implementing future
bounce protocols until after the installation of current software
implementing old protocols for lists, including support for RFC 2919
and RFC 2369. This mailing list is among the minority of IETF/IRTF
lists that has List-Id headers.
My point is about priorities and that this should be about fixing spam.
Perhaps bounces are a problem worth fixing despite the lack of
quantitative evidence. If so, they are down the list of spam problems.
I think more pressing and relevant issues include:
- defining "consent" and other terms of the art.
- specifying the implied consent implied by having a public address.
- listing the sorts of objectionable mail that this mailing list
cares about.
We've spilled 10's of 1000's of words on solutions that even their
advocates must agree can't help this year or next. Could there be a
moritorium on advocating wonderful solutions until the problem has
been sketched? Do we really need to re-invent SMTP-TLS with shared
certs or PKI as I think I saw done today? Maybe bounces from legitimate
mailing lists that might use a consolidated bounce format are a
significant problem, but are they a significant spam problem?
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg