On Monday 08 February 2010 17:35:39 I wrote:
On Saturday 06 February 2010 18:37:05 Dave CROCKER wrote:
...
Reports should be submitted using a mechanisms that:
[1] Is the same as for submitting regular new mail, that is,
normal posting. (Determination of the address to send to is a
separate issue.)
[2] Is specific to the mechanism for retrieving the message for
which a report is being submitted. (The details of such mechanisms
is a separate issue.)
I prefer [2].
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.
If the originating MTA(s) can be persuaded to hold onto [a copy of] the
original message for at least a few days the reporting MUA merely needs
to tell its upstream MTA which message(s) are spam/unwanted by
referring to their UIDLs or Message-IDs. In addition there seems to be
a greater chance of inadvertent disclosure of information with [1]
whereas with [2] we know the MTA has already seen the message.
I don't see POP3 as a problem with [2] as suggested elsewhere: It could
be extended to include reporting a UIDL (or Message-ID) as
spam/unwanted; unaltered implementations would simply answer
'unimplemented', which I don't see as a problem: If people like having
a spam button they can persuade their POP3 provider to implement the
server-side part of it or vote with their feet.
A further thought: If MUAs use the UIDL / MessageID of the TiS message to
communicate the message's spam/unwanted status there's not the issue of
poisoning to worry about, whereas with SMTP/ARF there is the potential for
malicious (false) ARF reports to be sent perhaps with the intent of
degrading ("poisoning") a competitor's email reputation.
I expect this can be addressed in the ARF model (e.g. using some form of
cookie mechanism) (maybe that's already been covered), but I mention it as
a plus point for model [2].
cheers,
Andrew.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg