ietf-asrg
[Top] [All Lists]

Re: [Asrg] Iteration #3.

2010-02-06 04:18:27
On 05/Feb/10 20:10, Chris Lewis wrote:
So we get rid of inband abuse report instructions altogether.

(I assume "report instructions" is not exactly the same as "reporting addresses", but what's the difference?)

I propose two specifications:

1) a spec for MUAs that says nothing more than "if the TiS button is
pushed, the selected email[s] get sent in ARF format to <some standard
address>, via the usual mail submission methods it uses". I recommend,
so as to not stomp/overload existing naming conventions, that it be
"arf(_at_)arf(_dot_)<domain in the RCPT TO that reached the user>". Or, "ar", or
whatever. I don't care what it is (if you really don't want to use
"arf") as long as it doesn't collide with existing conventions and
standards. Eg: IMAP/POP/SMTP/SPAM et. al. are unacceptable.

-1. It is perfectly legal for an IMAP server to be at 127.0.0.1, but that doesn't produce an email address by the above rule.

This argument is the opposite of what Derek said. That is, a convenience mailstore located on the recipient side of a message path may have no clue at all, and rely on its upstream servers for SPF/DKIM verifications, filtering, and reputation assessments.

This also allows <domain> to use DNS to map them to somewhere else
entirely.

If we reset the discussion why do we maintain that reports have to be sent by SMTP/MSA? IMAP is better (see below).

2) a followon spec that specifies what goes on at arf(_at_)arf(_dot_)<domain>" 
in
terms of remote report forwarding (if any). Rather than relying on
inband ARF destination signalling, I think we should consider doing
something with DNS ala SPF/SenderID and DKIM.

-1. Even if I haven't got what DNSish thing you mean, if we discard the message path we cannot distinguish botnets from reliable servers. Inband authentication traces are the keystones for handling non-criminal spam.

Astute readers will notice that (1) is a trivially simple MUA hack, and
that (2) isn't necessary for many installations wanting TiS info (for
filter tuning) and don't forward them anywhere.

For filter training you also need "ham" type submissions, which ARF is currently missing. In addition, you need to deliver uncertain messages, flagged as possible spam, e.g. in a "Junk" folder.

Although similar, the topic of how to properly synchronize server side filtering with client's Bayesian data is different from the idea of generalizing FBLs. My understanding is that this topic primarily concerns IMAP, since webmail and POP3 have no provisions for synchronizing contents. Ian's contributions look differently from this perspective, and imply that using IMAP directly is the best choice in this case.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg