On Monday 08 February 2010 18:05:06 Chris Lewis wrote:
Andrew Richards wrote:
What bugs me about [1] is that the whole message is being re-sent, but
we seem to have established that the only thing a spam button will be
saying is "This is spam/unwanted", so sending a report including the
original email for basically a single bit of information seems
excessive.
In general, it isn't a "single bit of information", especially if you
consider that this mechanism will undoubtably used to feed outsourced
handlers who don't see your inbound mailstream at all.
Think SpamCop for example.
I'm not sure why "exessive [volume]" is a particular concern.
Okay, let me rephrase that to "not elegant"
For the
most part complaints are relatively rare, and this is only on that
fraction that doesn't already get zapped by the filters. We're
exceptional in the former (getting as much as 10-20% of all spam getting
past the filters being reported as full forwards), but nobody has ever
noticed the flow operationally.
An example where this might be noticeable:
Bob receives a multi-megabyte email (with attachment etc) and decides to
press the TiS button. He's on a modest ADSL or dial-up link, so if he
returns the whole message in a report this will temporarily impact on his
bandwidth which he may well notice. If instead just a few packets are used
to communicate the unwanted UIDL / MessageID he'll not be troubled.
I think this is where elegance (= lightweight on bandwidth) helps in this
situation. At the same time I grant that this would be introducing an
additional burden on MTAs to store messages where they may not be doing so
at present.
If you posit 100% "hit the TiS button", 100% spam, and _no_ filtering
whatsoever, your outgoing from the user equals your incoming to the
user. But if you're in a situation like that, one wonders why you have
mail service or users at all.
cheers,
Andrew.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg