Re: [Asrg] Iteration #3.

["Chris Lewis" <[e-mail]>]

Alessandro Vesely wrote:
> On 05/Feb/10 20:10, Chris Lewis wrote:

> -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.

If an installation configures that way, then they don't want abuse 
reports.  If they do want them, they adjust how it's configured.

> 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 is not a problem.  The mailstore owner either configures DNS to 
make it happen properly, or elects not to.  Without necessarily having 
to involve the mailstore in the report flow.

And yet,

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

You just did it again.  This _forces_ technology dependence, requires 
that the mailstore implement abuse reporting mechanisms, and violates 
the whole idea of simplification so as to not dictate that any specific 
part of the mailflow other than the UA needs to know how to send an 
abuse report.

Spec #1 is _only_ how the UA finds out when TiS is enabled, and where to 
send SMTP'd reports (presumably ARFd).  If you want to go back to IMAP, 
that undoes both resets and goes back to something that probably 
disenfranchises most installations from being able to do this.

> -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.

All the message path information is in the ARF report, to be processed 
or not, as the abuse reporting service is designed. Including DKIM/SPF 
information etc.  Well, yes, the body could be S/Mime'd or PGP 
encrypted, but the report probably has all it needs in the header anyway.

Your argument presupposes that the UA can distinguish such things. 
Usually it can't.  Leave that to the report receiver.

>> 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,

Only if you're doing server-based Bayes and the abuse handling mechanism 
is separate from the inbound mail flow. You don't necessarily need 
user-end ham submissions if you can get at the mailflow.

> 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. 

It's in the ARF, so synchronization isn't necessary.