ietf-asrg
[Top] [All Lists]

Re: [Asrg] Consensus Call - submission via posting (was Re: Iteration #3)

2010-02-09 11:34:31
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

<Prev in Thread] Current Thread [Next in Thread>