From: Kee Hinckley <nazgul(_at_)somewhere(_dot_)com>
...
Why wouldn't RFC 2919 and RFC 2369 headers be sufficient?
We were discussing error codes for why a message was rejected and
what to do about. Those are list identification RFCs (which ties in
with another simultaneous discussion--but not this one).
???
Oh, I was confused. I think spending time on bounce formats is a
bigger waste of time than "internationalizing" error messages from
programs. In practice, computer error messages are always opaque
cybercrud to everyone except the priesthood. "ABEND 12345" may be a
bad joke, but not as bad as the jokes that claim to communicate computer
problems to people who are not experts. No matter what you put in
mail rejection messages, 99% of their recipients will have no clue
what is intended. However, I also know that I'm be in the minority
on all variations of this issue. Besides, even I agree that as long
as newly formalized bounces can be implemented, they're no worse than
a minor distraction and might even do a little good.
That leads to the purpose and future of this mailing list and group.
IRTF groups do not appear, deliver a solution in a few weeks, and
disappear. Research is not a short term effort. If it is successful,
this list will endure for years like the end-to-end list, with varyng
relevance and effects. The best that can be hoped is that it will
collect good ideas and support their developement or at least publication,
like ECN in end2end. There will always be other sorts of contributions
like IPv8 advocacy and notes from people who confuse TCP with TP0.
I think the immediate official goals have significantly been met:
- Paul has produced a taxonomy
I'm not sure how important it will be but it was necesary. The
many anti-spam product developers will not use it very precisely.
We are in competition with each other and spammers, and so will
keep some things more or less secret.
- I think communicating consent is hopeless and even a bad idea.
Advertisers will never entirely honor anything but "tell me more."
The only person who can be trusted to honor consent is the end user.
However, there might be something that could be done in a few months.
Other things that should be done include:
- words and definitions for common concepts such as mismatches between
reverse DNS name and envelope sender (Please not "forged")
- common practices such as ways that bulk mail should be identified
for white-listing.
- ideas for SMTP headers indicating filter results.
I've doubts that all of the many mail filter/markers can agree, but
maybe something is possible.
- improved mechanisms for opting-out of spam.
- provide a focus for IETF/IRTF attention to spam.
A problem is tha some of the work this list might do might belong in
one of the IETF WGs.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg