David MacQuigg wrote:
I think it is not a good idea to have users compose any message in
response to a spam. Much better if they can just hit a "Reject as
Spam" button, and know that the "Spam Bounce" will be handled promptly
All of the big end-user ISPs have this is some form or another, and the
actions they take vary a lot. There are also non-ISP "this is spam"
systems like Razor/Cloudmark and shared Bayesian systems, and of course
there's SpamCop. There is absolutely no consensus among these about what
"prompt and correct" handling means. For example, the mindset at AOL is
to stop their users from receiving unwanted messages. The mindset of
Razor/Cloudmark is to choke off spam messages from the whole community.
The mindset of most SpamCop users is to get spammer's kicked off their
AOL is driving an effort to standardize "this is spam" end-user
feedback, based on the considerable experience they have with their
existing FBL (feedback loop) mechanism. The BOF that AOL hosted at MAAWG
was pretty firey -- lots of strong feelings on specific issues, and
markedly different needs from different senders.
Do we agree that Spam Bounces should not go to the Return-Path? Do we
agree that reputable forwarders should want to receive these bounces?
Nope, we don't. Handling of "spam bounces" is a matter of local policy
and is an evolving subject.
And totally out of scope for the E-mail architecture document.