Subject: [Asrg] Iteration #3.

From: "Chris Lewis" <[email-masked]>
Date: Fri, 5 Feb 2010 14:10:45 -0500

We've more-or-less reset the discussion to emailing ARF reports (most 
people are satisfied with emailed ARF reports without other options)..

I think we need to reset it again, yet further.  The reason being that 
the discussion touches too many pieces at once, and the 
security/practicality issues of remotely-specified ARF destinations are 
obscuring the fact that why bother with specifying them at all?  Let the 
user's ARF handling service do it.  We need to very specifically 
disentangle MUA/MTA functions and simplify yet again.

So we get rid of inband abuse report instructions altogether.

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

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

Then,

2) a followon spec that specifies what goes on at arf@arf.<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.

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.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Feb 2010 11:22:40 -0800

On 2/5/2010 11:10 AM, Chris Lewis wrote:
> address>, via the usual mail submission methods it uses".

+1

This greatly simplifies the model and the specification details.  At that, there 
is still plenty to debate.  (I'm not going into the details of what I happen to 
this is the 'plenty' because the higher-level concern is creating a simplified, 
focused effort.)

> something with DNS ala SPF/SenderID and DKIM.

+ 0.5.

I suspect this will be much more difficult to work on, because I suspect there 
is far less de facto industry consensus on the topic.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Steve Atkins <[email-masked]>
Date: Fri, 5 Feb 2010 11:29:43 -0800

On Feb 5, 2010, at 11:10 AM, Chris Lewis wrote:

> We've more-or-less reset the discussion to emailing ARF reports (most people are satisfied with emailed ARF reports without other options)..
> 
> I think we need to reset it again, yet further.  The reason being that the discussion touches too many pieces at once, and the security/practicality issues of remotely-specified ARF destinations are obscuring the fact that why bother with specifying them at all?  Let the user's ARF handling service do it.  We need to very specifically disentangle MUA/MTA functions and simplify yet again.
> 
> 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@arf.<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 for "MUA sends a report in ARF format to <some address>"

What that address should be, and how the MUA should discover it without manual configuration, is the interesting bit.

> 
> Then,
> 
> 2) a followon spec that specifies what goes on at arf@arf.<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.

It's a can of worms buried in a rathole behind a bikeshed that needs painting.

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

Cheers,
  Steve

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 5 Feb 2010 14:56:37 -0500

> It's a can of worms buried in a rathole behind a bikeshed that needs painting.

Yeah, but we don't _need_ (2) to have accomplished something useful.

Maybe (2) never gets done.  Even if (2) is never specified, most admins 
will not need it because they don't intend on forwarding them anywhere 
anyway and, secondly, if they do want to forward them, they at least 
have something to base automated forwarding of some to select 
hand-crafted destinations.

---

From: Derek Diget <[email-masked]>
Date: Sat, 06 Feb 2010 02:28:42 -0500 (EST)

On Feb 5, 2010 at 14:10 -0500, Chris Lewis wrote:
=>We've more-or-less reset the discussion to emailing ARF reports (most people
=>are satisfied with emailed ARF reports without other options)..

+1

=>I think we need to reset it again, yet further.  The reason being that the
=>discussion touches too many pieces at once, and the security/practicality
=>issues of remotely-specified ARF destinations are obscuring the fact that why
=>bother with specifying them at all?  Let the user's ARF handling service do
=>it.  We need to very specifically disentangle MUA/MTA functions and simplify
=>yet again.

+1

=>So we get rid of inband abuse report instructions altogether.
=>
=>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@arf.<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.
=>
=>This also allows <domain> to use DNS to map them to somewhere else entirely.

-1 for having a "standard" address.  Let sites decided.  Some might want 
them to go to abuse@, spam@, devnull@, [email-masked].  

I have deleted the message, but Thursday someone (you?) had a post with 
regard to having the final MTA insert a header with the ARF reporting 
address?  I like that idea, but would replace MTA with MDA.  An MTA 
never really knows if it is the "last" MTA, where an MDA does.

The MDA should be within a trust/security zone of the MUA user since 
they are retrieving their message from it.  (Doesn't matter how they 
retrieve them be it webmail, IMAP, POP, fetchmail, SSH, NFS, pigeon.)  
The MDA could be made to insert different reporting addresses in a 
hosted domain environment thus allowing mailDomainA recipients use 
reportingAddressA and mailDomainB recipients use reportingAddressB.

I get the feeling people are still trying to tie the message retrieval 
MUA configuration with the MUA's submission configuration.  Why?  Is it 
a bad assumption that the MUA is not already configured to send messages 
via some MSA?  If not, then use the MSA.  (Clients like Thunderbird 
would need to pick the right MSA for the "identity/persona" when users 
have multiple MSA systems configured.)

So, if companyA/universityB/hostingCompanyC/dogAndFamilyHobbiestD want 
to let their user's use a TiS button, they insert[1] the TBDheader with 
the reporting address for the recipients domain.  (Note that 
[email-masked] and [email-masked] might get delivered into the same 
folder of the message store, but the MDA could be configured to inserted 
different reporting addresses for the different recipient domains.)  
When the user click the TiS button, the MUA sends the ARF report using 
the MSA that it has configured for the user's identity/persona that 
matches where the message was retrieved from.  (Note how this even works 
for webmail based MUA.)

Where I see my suggestion break down is on the deliverability of the ARF 
when a MUA is configured to retrieve message from one message store 
(companyA), but use ISP-b's MSA.  ISP-b might reject/quarantine/discard 
the ARF if it is scanning it user's out-bound mail and thus the ARF 
reporting address for companyA never gets the user's message.  (So, if 
companyA wants to get their user's ARF messages, they needs to be 
running a MSA that their user's can use, tell them to use, and require 
them to use. :)

1: I think having the option of reporting back up the delivery chain 
several hops currently creates to many potential issues.  Let just start 
with the MDA removing any existing headers and putting the one that works 
for user's "local" address.

--
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 06 Feb 2010 11:18:11 +0100

> 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?)

> 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

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

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

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

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 6 Feb 2010 12:34:34 -0500

> them to go to abuse@, spam@, devnull@, [email-masked].  

Defeats the purpose of self-configuration, UNLESS the mailstore provider 
can automatically provide it.  See my posting under "We don't need no 
stinking..." for a method to do it with TXT records.

> never really knows if it is the "last" MTA, where an MDA does.

We don't want to modify _anything_ in the mail stream if we can possibly 
avoid it.  If we do, sites can't do this without infrastructure changes 
(which may never happen in some environments).  Eg: if Microsoft elects 
not to follow this spec, we've just disenfranchised Exchange environments.

Having it purely in the UA, and perhaps DNS for signalling, make it a 
_lot_ easier to deploy.

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 6 Feb 2010 12:55:24 -0500

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

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

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

> Inband authentication traces are the keystones for handling 

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.

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

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

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 06 Feb 2010 10:37:05 -0800

On 2/6/2010 9:55 AM, Chris Lewis wrote:
> You just did it again. This _forces_ technology dependence,

My reading was that the group appeared to converge on using regular posting for 
submitting a report.

But perhaps the presence of rough consensus needs to be determined explicitly.

Would folks please respond to the list with their preference:

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

d/
-- 

   Dave Crocker

---

From: "Lyndon Nerenberg (VE6BBM/VE7TFX)" <[email-masked]>
Date: Sat, 6 Feb 2010 11:50:58 -0700

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 6 Feb 2010 14:36:49 -0500

---

From: Steve Atkins <[email-masked]>
Date: Sat, 6 Feb 2010 12:42:06 -0800

On Feb 6, 2010, at 10:37 AM, Dave CROCKER wrote:

> My reading was that the group appeared to converge on using regular posting for submitting a report.
> 

For completeness there's also 

 [3] Is the same for every mechanism for retrieving the message,
      but not based on submitting email.

... for example, reporting via an HTTP post, or an SMTP extension,
or XMPP, or telepathy, regardless of whether the original message
was read via POP, IMAP, spool access, SMTP ETRN, SMS or an
XML-RPC call.

I think [1] is the right way to go, though.

Cheers,
  Steve

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 06 Feb 2010 14:17:18 -0800

Just to be clear:  the purpose of a consensus call is to resolve ambiguity about 
preferences among choices being discussed.

So I listed the choices that I had seen dominating the discussion, rather than 
listing among a full range of theoretical -- albeit possibly quite reasonable -- 
choices.

If there is a consensus that /neither/ of the two listed choices is preferred, 
then a more careful listing and consideration of alternatives would make sense.

d/

On 2/6/2010 12:42 PM, Steve Atkins wrote:
> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg
>

-- 

   Dave Crocker

---

From: Dotzero <[email-masked]>
Date: Sat, 6 Feb 2010 18:13:58 -0500

On Sat, Feb 6, 2010 at 5:17 PM, Dave CROCKER <[email-masked]> wrote:
> Just to be clear:  the purpose of a consensus call is to resolve ambiguity
> about preferences among choices being discussed.
>
> So I listed the choices that I had seen dominating the discussion, rather
> than listing among a full range of theoretical -- albeit possibly quite
> reasonable -- choices.
>
> If there is a consensus that /neither/ of the two listed choices is
> preferred, then a more careful listing and consideration of alternatives
> would make sense.
>
> d/
>
>

I've been sitting on the sidelines watching this discussion with
interest. I lean towards #1.

---

From: Derek Diget <[email-masked]>
Date: Sat, 06 Feb 2010 21:15:45 -0500 (EST)

On Feb 6, 2010 at 12:34 -0500, Chris Lewis wrote:
=>Derek Diget wrote:
=>
=>> =>This also allows <domain> to use DNS to map them to somewhere else
=>> entirely.
=>> 
=>> -1 for having a "standard" address.  Let sites decided.  Some might want
=>> them to go to abuse@, spam@, devnull@, [email-masked].  
=>
=>Defeats the purpose of self-configuration, UNLESS the mailstore provider can
=>automatically provide it.  See my posting under "We don't need no stinking..."
=>for a method to do it with TXT records.

One of the problems I have with publishing "private" (spammers and DNS 
walkers don't need to know this stuff) configuration information is that 
people that don't need to know it can get it.  Using SRV records to 
auto-config MUA retrieval and MSA settings or XMPP clients are different 
in that knowing those settings can't be abused unless you have a valid 
authentication credential.  Whereas, publishing an e-mail address is 
just asking for it to abused.  (Heck, how many spammers are not smart 
enough to list wash abuse@, postmaster@ and the other role accounts 
from their lists.  Do you think they won't start sending non-ARF 
messages (regular) spam to the TiS reporting address.  (Yes, some would 
say that is good as it will just help block/filter them, but I am  
thinking more about the increase in volume to the TiS reporting 
address.)

I am also thinking of spammers walking DNS and getting the reporting 
addresses and then sending ham to it to try to mess up the sites that 
might be automatically processing their TiS messages.  If the reporting 
address is in a header then they (spammer) would have a harder time 
getting the address.  (Yes, with all of the compromised PCs, free 
accounts, etc they can still probably get it anyways.)

=>> I have deleted the message, but Thursday someone (you?) had a post with
=>> regard to having the final MTA insert a header with the ARF reporting
=>> address?  I like that idea, but would replace MTA with MDA.  An MTA never
=>> really knows if it is the "last" MTA, where an MDA does.
=>
=>We don't want to modify _anything_ in the mail stream if we can possibly avoid
=>it.  If we do, sites can't do this without infrastructure changes (which may
=>never happen in some environments).  Eg: if Microsoft elects not to follow
=>this spec, we've just disenfranchised Exchange environments.

I have not been involved in a MS Exchange environment, but 1) I think 
that it already have a TiS mechanism builtin and 2) it is a closed 
environment like Lotus Notes, and Novell Groupwise.  Sites running those 
systems would be on their own.  (Yes, they might support IMAP/POP, but 
is a third-party client "supported for use" by their IT departments?)

---

From: Derek Diget <[email-masked]>
Date: Sat, 06 Feb 2010 21:18:45 -0500 (EST)

On Feb 6, 2010 at 10:37 -0800, Dave CROCKER wrote:
=>But perhaps the presence of rough consensus needs to be determined explicitly.
=>
=>Would folks please respond to the list with their preference:
=>     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.)

+1

---

From: Bart Schaefer <[email-masked]>
Date: Sat, 06 Feb 2010 18:46:53 -0800

+1

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 07 Feb 2010 07:33:29 +0100

> posting for submitting a report.

+1. However, that necessarily depends on the nature of the reports 

>         posting.  (Determination of the address to send to is a separate

The former suits well "generalized FBLs", and ARF.

>         report is being submitted.  (The details of such mechanisms is a

The latter is better for maintaining Bayesian data on the servers, 
an apparently related topic.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 07 Feb 2010 10:37:31 +0100

> user-end ham submissions if you can get at the mailflow.

IME, FPs increase after spam training and the only remedy I've been 
able to find is to do ham training with messages manually retrieved 
from spam folders. For POP3 users, you have no way to know which 
messages they discard, either manually or automatically, and which 
they consider ham. How do you tune the filter using just the mail flow?

---

From: Daniel Feenberg <[email-masked]>
Date: Sun, 7 Feb 2010 07:16:01 -0500 (EST)

> accounts, etc they can still probably get it anyways.)

For this reason the MTA operator would probably want to discard messages 
to the arf reporting address unless they were submitted via the MSA 
submission port, or came from inside the MTA operators own network. These 
are the same criteria that determine if a message is acceptable for relay, 
and so should easily be programmed in the MTA software.

Daniel Feenberg

---

From: John Levine <[email-masked]>
Date: 7 Feb 2010 16:30:40 -0000

> For this reason the MTA operator would probably want to discard
> messages to the arf reporting address unless they were submitted via
> the MSA submission port, or came from inside the MTA operators own
> network.

That doesn't sound like a very good idea.  When I was providing mail
for the customers of a local web hosting company, I tried really hard
to get them to use my MSA, since it made the management and trouble
diagnosis a lot easier.  No matter what I did, I never got more than
half of them to do so.  The rest just used some other account,
generally their local ISP, because it mostly worked.

These days lots of people pick up their mail from Gmail, but who knows
how they send it.  I know people who have Gmail pick up their ISP
mailbox since they like the sorting and spam filtering better, but did
they change their outgoing setup?  I doubt it.

Once again, I would ask people to try really hard to avoid assuming
that all, or even many, mail systems are just like yours, since that
leads to false assumtions and poor designs.

R's,
John

---

From: Daniel Feenberg <[email-masked]>
Date: Sun, 7 Feb 2010 11:42:25 -0500 (EST)

> leads to false assumtions and poor designs.

I said "probably". There are certainly other ways the MTA operator could 
distinguish legitimate reports from forgeries, if necessary.

Daniel Feenberg

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 07 Feb 2010 09:01:18 -0800

On 2/7/2010 4:16 AM, Daniel Feenberg wrote:
> submission port, or came from inside the MTA operators own network.

The question of differentiating between reports that come from within the 
operator's trust boundary, versus from outside of it, is certainly reasonable to 
worry about for a reporting mechanism like this.

Exactly how to resolve that question might be easy or difficult, probably 
depending upon tradeoffs between false rejection of reports vs. false acceptance 
of them...

For some environment, I'd expect your simple rule to be entirely adequate.

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 7 Feb 2010 19:50:19 -0000

>For some environment, I'd expect your simple rule to be entirely adequate.

I suppose so, although I can't figure out how a system could tell that
it was in such an environment.

Since the reports all contain a message that was supposed to be
delivered by the system to which it was returned, a straightforward
way to recognize real reports would be to check the enclosed message
to see if it looked like something it had delivered.  That seems much
more robust against both malicious forgery, and plain old mistakes
where an MUA picks up mail from two different places and sends the
report to the wrong one.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 07 Feb 2010 12:06:35 -0800

> where an MUA picks up mail from two different places and sends the

encoding per-channel information in a per-message package is a mismatch that 
could be problematic.

most seriously is the possibility of trust boundary issues that has already been 
raised.  i had a further thought on that issue, which is about unintentional 
disclosure through forwarding.

d/
-- 

   Dave Crocker

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 08 Feb 2010 12:43:13 +0000

>            report is being submitted.  (The details of such mechanisms is 
a

I prefer [2].

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: John Levine <[email-masked]>
Date: 8 Feb 2010 14:14:03 -0000

>           report is being submitted.  (The details of such mechanisms is a

Has to be [1], to make it work reasonably for the legions of POP users.

R's,
John

---

From: "BOBOTEK, ALEX (ATTCINW)" <[email-masked]>
Date: Mon, 8 Feb 2010 08:50:12 -0800

Less coupling to the access protocol (e.g., POP, IMAP) is better IMO.  1
is better than 2.  

Report submission methods should, to the extent practical, be
independent of the access protocol.  

Regards,

Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dave CROCKER
Sent: Saturday, February 06, 2010 2:17 PM
To: Anti-Spam Research Group - IRTF
Cc: Steve Atkins
Subject: Re: [Asrg] Consensus Call - submission via posting (was Re:
Iteration #3)

Just to be clear:  the purpose of a consensus call is to resolve
ambiguity about 
preferences among choices being discussed.

So I listed the choices that I had seen dominating the discussion,
rather than 
listing among a full range of theoretical -- albeit possibly quite
reasonable -- 
choices.

If there is a consensus that /neither/ of the two listed choices is
preferred, 
then a more careful listing and consideration of alternatives would make
sense.

d/

-- 

   Dave Crocker

---

From: "Andrew Richards" <[email-masked]>
Date: 8 Feb 2010 17:35:39 +0000

On Saturday 06 February 2010 18:37:05 Dave CROCKER wrote:
> ...
>       [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.

cheers,

Andrew.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 08 Feb 2010 09:39:27 -0800

> email for basically a single bit of information seems excessive.

The alternative requires that a copy of the message still be at the server. 
That works in only some MUA-based models.  Often/typically, the entire message 
is downloaded to the MUA's site and the server no longer has a copy.  Hence, 
it's too late to enjoy merely passing a citation back to the server.

> their UIDLs or Message-IDs. In addition there seems to be a greater chance

The challenge is the "few days".  It means that the mechanism fails after a few 
days.  Is that acceptable?  Why?

d/
-- 

   Dave Crocker

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 8 Feb 2010 13:05:06 -0500

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

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.

---

From: "Andrew Richards" <[email-masked]>
Date: 8 Feb 2010 19:19:06 +0000

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.
> 
> I'm not sure why "exessive [volume]" is a particular concern.

Okay, let me rephrase that to "not elegant"

> For the

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.

cheers,

Andrew.

---

From: "Andrew Richards" <[email-masked]>
Date: 8 Feb 2010 20:56:23 +0000

On Monday 08 February 2010 19:18:30 Dave CROCKER wrote:
> On 2/8/2010 11:11 AM, Andrew Richards wrote:
> >> The alternative requires that a copy of the message still be at the
> >>   server. That works in only some MUA-based models.  Often/typically,
> >> the entire message is downloaded to the MUA's site and the server no
> >> longer has a copy.  Hence, it's too late to enjoy merely passing a
> >> citation back to the server.
> >
> > I wish to imply that it would become a requirement for the server to
> > hold a copy if it wishes to implement this functionality
> 
> That creates a massive barrier to adoption.  Huge implementation
>  overhead.

However TiS is implemented will require implementation work on the server-
side, so I'm not sure that [2] is so different from [1] in this respect.

> >> The challenge is the "few days".  It means that the mechanism fails
> >>   after a few days.  Is that acceptable?  Why?
> >
> > Reports of spam are most useful the fresher they are
> 
> while no doubt true, it is not a clear to me that it's appropriate to
>  make it impossible to submit older reports.

MTA admins may choose how long to retain copies of messages, perhaps 
subject to a suggested minimum. So yes it would be impossible in some 
cases, but is that a problem if 95% of spam can be successfully reported 
(95% of reports being fresh enough for the message still to be held by the 
MTA)? Losing 5% of reports is perhaps worthwhile if this approach has other 
advantages, I would suggest a greater elegance (no squandered bandwidth, 
see separate post) and a safer security model re. information leakage. I am 
of course pulling my 95%/5% figures out of thin air. The MTA admin has an 
incentive to retain copies for a reasonably long time to maximise his/her 
anti-spam capabilities.

Alternatively to address that 5%, and perhaps relevant to other TiS 
approaches, if MTAs had the option of retaining messages for TiS purposes, 
if the report-submission was interactive (such as Steve Atkins option [3] 
'for completeness' posted on 6th Feb which I've pasted below) the MUA could 
query whether the upstream system already has a copy of the message. For 
example I would note that IMAP servers have a good chance of having the 
message. The MUA can then report TiS messages where a copy has been kept 
without inadvertent information leakage, and might have a user setting 
whether to send a full report where no copy has been kept.

cheers,

Andrew.
---------
Steve's option [3]:

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 08 Feb 2010 13:08:03 -0800

> side, so I'm not sure that [2] is so different from [1] in this respect.

The nature and amount of change on the server sides depends on quite a few things.

Certainly there needs to be software at the reporting mailbox, to process 
reports.  That's a fixed requirement and it's outside the scope of the current 
discussion.

What remains is differential cost, security and efficacy choices for signaling 
the reporting address to the MUA.

The DNS approach will tend to be somewhere between free and cheap for mainstream 
uses.

The message-header-field approach is probably pretty cheap, but introduces trust 
concerns.  It might also have a per-protocol server cost, depending on whether 
it's possible to affix the header before the retrieval protocol server comes 
into play.

The in-protocol approach is probably relatively cheap, but definitely has a 
per-retrieval protocol cost.

None of these have the kind of synchronization issues your proposal calls for.

> cases, but is that a problem if 95% of spam can be successfully reported

You are making an assumption and validating it requires empirical data. I 
haven't seen any.  Unless you have, the 5% you cite is merely a measure of your 
hope, not a measure of what we can expect to be true.  In addition, the fact 
that the design guarantees that there is /some/ time limit is a design 
limitation worth worrying aobut.

d/
-- 

   Dave Crocker

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 8 Feb 2010 16:13:09 -0500

> side, so I'm not sure that [2] is so different from [1] in this respect.

If the MUA is manually configured, it requires zero implementation 
effort on the server end, and if configured thru MDA header insertion 
(eg: Something RFC5451ish), it may still only need a configuration 
change, not a code change.

_We_ can do TiS button correlation to a spooled copy (within expiration 
limits), and in fact we use it now.

[There's a couple technical reasons for it being done this way, but as 
implemented _now_, this is just a short-cut to make sure we can snip out 
the _correct_ logging information, and don't need to look at the body, 
whether stored or forwarded.]

But we're corporate, we have employee agreements that state that we can 
do this.  I'd hate to be <large ISP> and have to be answering the media 
frenzy if EFF found out we were preserving all email this way.

Forwarding the email is a deliberate action on the user's part, and you 
can easily handle privacy issues if you pay attention during 
implementation and deployment.  If you insist on retaining everything 
for everybody so as to do abuse reporting from a subset of your users, 
privacy can become a much more difficult issue, and a much bigger 
implementation one to program around privacy issues (eg: only doing it 
for users who've shown they want this).

---

From: John Levine <[email-masked]>
Date: 9 Feb 2010 01:20:39 -0000

>The DNS approach will tend to be somewhere between free and cheap for
>mainstream uses.

I keep seeing this assertion, but it makes no sense.  As a concrete
example, here's the DNS for the POP server for BT Internet, the largest
ISP in the UK.  Can you describe the DNS changes needed if they were
publishing a spam button address?

R's,
John

$ dig  mail.btinternet.com a
;; ANSWER SECTION:
mail.btinternet.com.    600     IN      CNAME   pop-smtp.bt.mail.yahoo.com.
pop-smtp.bt.mail.yahoo.com. 1800 IN     CNAME   pop-smtp.bt.mail.fy5.b.yahoo.com.
pop-smtp.bt.mail.fy5.b.yahoo.com. 300 IN A      217.12.13.134
pop-smtp.bt.mail.fy5.b.yahoo.com. 300 IN A      217.146.188.192

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 08 Feb 2010 17:39:23 -0800

> pop-smtp.bt.mail.fy5.b.yahoo.com. 300 IN A      217.146.188.192

I don't hack DNS records enought to be sure, but it appears to need exactly one 
new record:

_report.pop-smtp.bt.mail.fy5.b.yahoo.com IN TXT   [email-masked]

or perhaps I'm wrong and it needs a whopping 3 new records:

_report.pop-smtp.bt.mail.fy5.b.yahoo.com IN TXT   [email-masked]

_report.pop-smtp.bt.mail.yahoo.com IN TXT   [email-masked]

_report.mail.btinternet.com IN TXT   [email-masked]

-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 8 Feb 2010 21:28:10 -0500

> I don't hack DNS records enought to be sure, but it appears to need exactly 
> one new record:
>

Nope, that won't work.  CNAMEs don't do a partial match.

> _report.mail.btinternet.com IN TXT   [email-masked]

That won't work, either.  You can't have DNS records below a CNAME.

By the way, I was wrong about SRV records.  This DNS hack just doesn't 
work, but it won't work much more elegantly with RP records.  See RFC 
1183.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Bill Cole <[email-masked]>
Date: Mon, 08 Feb 2010 23:11:57 -0500

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 9 Feb 2010 07:11:58 -0500 (EST)

On Mon, 8 Feb 2010, John R Levine wrote:

> By the way, I was wrong about SRV records.  This DNS hack just doesn't work, 
> but it won't work much more elegantly with RP records.  See RFC 1183.
>

What is the objection to attaching the TXT record to the A record? I 
realize that it means that a single arf-reporting system must serve 
several CNAMEs, but that is a common requirement for many network 
services, and I rarely see complaints about it.

Daniel Feenberg

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 12:55:19 +0000

--On 8 February 2010 09:39:27 -0800 Dave CROCKER <[email-masked]> wrote:

> server. That works in only some MUA-based models.  Often/typically, the
> entire message is downloaded to the MUA's site and the server no longer
> has a copy.  Hence, it's too late to enjoy merely passing a citation back
> to the server.

Both IMAP and POP are capable of operating in a suitable manner. If the 
message isn't on the mailstore, then the operator has no way to check that 
the report really is about a message that they delivered.

>> 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
>
> The challenge is the "few days".  It means that the mechanism fails after
> a few days.  Is that acceptable?  Why?

Actually, that's completely implementation dependant. When a server gets a 
message "x is junk", it can either act immediately or it can queue an 
action.

For IMAP, it should make a safe working copy, then apply a flag or 
annotation acknowledging the report. At this point, the user/client knows 
its safe to delete the message, though they may prefer to keep it for later 
reference. Alternatively, the flag could be used to change the behaviour of 
the DELETE or EXPUNGE commands. For example, there's a patch for Cyrus IMAP 
which implements delayed expunge - messages are removed from the mailbox 
index, but aren't deleted from the file system until they've had a chance 
to be backed up (eg, after 24 hours). It's not hard to imagine a similar 
mechanism that handles messages with junk flags.

For POP, you'd probably make a safe copy then delete the original message. 
If the user wants a copy, they can download it before making the report.

In neither case is there a requirement for the message to continue to be 
visible to the recipient, or use any of their quota.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 13:03:18 +0000

> handlers who don't see your inbound mailstream at all.

A report to the mailstore operator need not be more than a few bits. I'd 
advocate at least two bits ("block" and "report"). But the value of the 
reports lies in crowd-sourcing them.

> I'm not sure why "exessive [volume]" is a particular concern.

It's a concern for users on low bandwidth connections. For example, my most 
frequent general complaints about spam volume come from people working in 
the field in countries with poor infrastructure. They want the most 
efficient access to mail that they can get. That means NOT downloading 
messages that they want to report as junk.

We're also seeing significant use of mobile devices for email - mostly 
iPhones at the moment. We expect to see that increasing.

Certainly the people with most incentive to report junk, are the ones with 
highest volumes of junk, and lowest bandwidth access.

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

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 13:08:53 +0000

> side, so I'm not sure that [2] is so different from [1] in this respect.

Well, the one huge difference is that an SMTP report [1] might be sent 
anywhere, and the mailstore operator may never see them.

A mailstore report [2] can only be sent to the mailstore operator - it's 
then the business of the operator to aggregate and act upon those reports, 
perhaps by forwarding some of them elsewhere.

So, one question that requires answering is "who's ultimately in control 
here: the operator or the user?"

---

From: "Andrew Richards" <[email-masked]>
Date: 9 Feb 2010 13:10:00 +0000

On Monday 08 February 2010 21:13:09 Chris Lewis wrote:
> >>>>   server. That works in only some MUA-based models. 
> >>>> Often/typically, the entire message is downloaded to the MUA's site
> >>>> and the server no longer has a copy.  Hence, it's too late to enjoy
> >>>> merely passing a citation back to the server.
> >>>
> > However TiS is implemented will require implementation work on the
> > server- side, so I'm not sure that [2] is so different from [1] in
> > this respect.
> 

I take your point on privacy. Would the following address this point:

The MUA communicates to the upstream provider for TiS for the model I'm 
advocating, so the MUA could use the same method to signal to the upstream 
provider if it's okay to retain messages for TiS purposes and for how long. 
The user has then 'opted-in' to having their messages retained.

cheers,

Andrew.

---

From: "Andrew Richards" <[email-masked]>
Date: 9 Feb 2010 13:31:12 +0000

On Monday 08 February 2010 21:08:03 Dave CROCKER wrote:
> Certainly there needs to be software at the reporting mailbox, to
>  process reports.  That's a fixed requirement and it's outside the scope
>  of the current discussion.
> 
> What remains is differential cost, security and efficacy choices for
>  signaling the reporting address to the MUA.
> 
> The message-header-field approach is probably pretty cheap, but
>  introduces trust concerns.  It might also have a per-protocol server
>  cost, depending on whether it's possible to affix the header before the
>  retrieval protocol server comes into play.
> 
> The in-protocol approach is probably relatively cheap, but definitely
>  has a per-retrieval protocol cost.
> 

By synchronisation issues I'm not sure what you mean. If you mean the 
upstream system matching UIDL / Message IDs with the stored messages, I 
don't see this as particularly difficult - but I sense you have other issues 
in mind, please explain.

> You are making an assumption and validating it requires empirical data.
>  I haven't seen any.  Unless you have, the 5% you cite is merely a
>  measure of your hope, not a measure of what we can expect to be true. 
>  In addition, the fact that the design guarantees that there is /some/
>  time limit is a design limitation worth worrying aobut.

I don't see empirical data quoted for the other approaches either at 
present (although I am a newbie here so do correct me if I've got that 
wrong). As I stated I pulled my figures out of thin air. If there's sufficient 
interest in this approach then my assertions can be tested against real-
world data (we'd need a helpful volunteer already implementing TiS - 
probably in webmail - to generate data on how long it takes 'normal' users 
to report TiS from initial message retrieval).

Also see my separate post responding to Chris Lewis re. privacy issues 
where one could have the user/MUA specify the upstream retention period.

cheers,

Andrew.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 14:58:47 +0000

--On 9 February 2010 13:31:12 +0000 Andrew Richards 
<[email-masked]> wrote:

> (we'd need a helpful volunteer already implementing TiS -
> probably in webmail - to generate data on how long it takes 'normal'
> users  to report TiS from initial message retrieval).
>

My guess is that won't help. There's not really a "message retrieval" stage 
in webmail. The client never downloads anything.

With IMAP, there's also not really a message retrieval stage. With POP, 
there is, but with either, the most efficient thing is to NOT retrieve spam 
messages. Often they can be deleted on the basis of a preview of headers 
and part of the body.

If you're applying a flag or annotation to the message, you still don't 
retrieve it. And, in POP you generally can't act on deleted messages. In 
IMAP you generally can't act on expunged messages, so I don't see that with 
either protocol there's necessarily a problem that you might be reporting a 
message that isn't on the server any more. That only occurs if you've done 
a blind retrieval of all your messages in POP.

---

From: "Andrew Richards" <[email-masked]>
Date: 9 Feb 2010 15:08:29 +0000

On Tuesday 09 February 2010 14:58:47 Ian Eiloart wrote:
> My guess is that won't help. There's not really a "message retrieval"
>  stage in webmail. The client never downloads anything.

A better way of expressing myself would be "...how long it takes 'normal' 
users to report TiS for a message from its first presentation to the user" 
which would cover the user deleting messages purely based on the message 
preview you mention below.
 
> there is, but with either, the most efficient thing is to NOT retrieve
>  spam messages. Often they can be deleted on the basis of a preview of
>  headers and part of the body.
> 
> IMAP you generally can't act on expunged messages, so I don't see that
>  with either protocol there's necessarily a problem that you might be
>  reporting a message that isn't on the server any more. That only occurs
>  if you've done a blind retrieval of all your messages in POP.

cheers,

Andrew.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 15:18:40 +0000

--On 9 February 2010 15:08:29 +0000 Andrew Richards 
<[email-masked]> wrote:

> users to report TiS for a message from its first presentation to the
> user"  which would cover the user deleting messages purely based on the
> message  preview you mention below.
>

Yes. I guess my point is that information about user behaviour in a webmail 
client isn't relevant to the behaviour of users with a POP client.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Feb 2010 07:30:17 -0800

On 2/8/2010 6:28 PM, John R Levine wrote:
>> I don't hack DNS records enought to be sure, but it appears to need
>> exactly one new record:
>>

Then I guess it's lucky I didn't specify one.

> That won't work, either. You can't have DNS records below a CNAME.

I'm not finding where that restriction specified among the list of restrictions 
I can find, and apparently all of popular the summaries written about CNames 
have missed it too.

Please cite the standards text that specifies it.

d/
-- 

   Dave Crocker

---

From: Paul Russell <[email-masked]>
Date: Tue, 09 Feb 2010 10:50:01 -0500

> preview you mention below.

The vast majority of the complaints we receive about spam sent from compromised
accounts arrive within 2 days of the incident.  In several cases, we received
reports 4-6 weeks after the incidents.  In one case, we received a report nearly
4 months after the incident.  There is probably no practical reason to report
anything more than 3 days old.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame

---

From: "John R Levine" <[email-masked]>
Date: 9 Feb 2010 11:40:51 -0500

> Then I guess it's lucky I didn't specify one.

But you did.  The CNAME only matches its exact name, and doesen't do a 
partial match of names below it.  RFC 2181 explains this, albeit not very 
clearly.  DNAME does what you think CNAME does, but almost nobody 
implements it because the record synthesis it requires is so complex.

> I'm not finding where that restriction specified among the list of 
> restrictions I can find, and apparently all of popular the summaries written 
> about CNames have missed it too.
>

Also 2181.  I'll go see if there's a clearer explanation somewhere else.

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Feb 2010 08:51:19 -0800

On 2/9/2010 8:40 AM, John R Levine wrote:
> clearly.

Where did I or anyone else specify a partial match?

>> restrictions I can find, and apparently all of popular the summaries
>> written about CNames have missed it too.
>>

Normally, something finer-grained that a reference to all of 15 pages would be 
expected.

And here it is essential, because I still do not see its specifying what you are 
claiming.

Please cite the specific text that asserts the constraint that you believe makes 
it illegal to have a subdomain name, under a domain with a CNAME.

d/
-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 9 Feb 2010 12:11:36 -0500

> Where did I or anyone else specify a partial match?

The user thinks his POP server is called mail.btinternet.com.  When he 
looks up _report.mail.btinternet.com, what do you expect to happen?

> Normally, something finer-grained that a reference to all of 15 pages would 
> be expected.

Aw, come on.  If you can't find the part about CNAMEs in 10 seconds, 
you're not trying.

Regards,

---

From: "Andrew Richards" <[email-masked]>
Date: 9 Feb 2010 17:34:18 +0000

On Monday 08 February 2010 17:35:39 I wrote:
> >  normal posting.  (Determination of the address to send to is a
> > separate issue.)
> >
> >  which a report is being submitted.  (The details of such mechanisms
> > is a separate issue.)
> 
> I prefer [2].
> 
>  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.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 09 Feb 2010 17:44:20 +0000

--On 9 February 2010 17:34:18 +0000 Andrew Richards 
<[email-masked]> wrote:

> 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
> cookie mechanism) (maybe that's already been covered), but I mention it
> as  a plus point for model [2].

Quite, and nor does the client have to worry about when to delete the 
message. For a POP server, flagging will probably have that effect. For 
IMAP, the "deleted" and "user identified this message as junk" filters are 
orthogonal.

I'd expect both servers to advertise the facility as a capability, so 
there's no guessing as to whether to display the button, and no worries 
about trusting (!) headers in the junk message.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Feb 2010 10:34:44 -0800

> looks up _report.mail.btinternet.com, what do you expect to happen?

He'll get a TXT record back.  This is nothing but exactly the same mechanism 
that is used for DKIM and SRV, albeit with a different underscore subdomain.

The DNS construct of partial matching has nothing to do with this mechanism.

>> Normally, something finer-grained that a reference to all of 15 pages
>> would be expected.
>

You are asserting a truth.  It's your obligation to substantiate it.  A broad 
reference to a 15-page document does not satisfy that obligation.

I told you I looked for it and could not find it.  Rather than berate me, all 
you have to do to settle the matter is supply the text.  From what you say, 
that's a 10-second exercise.

d/
-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 9 Feb 2010 14:05:14 -0500

> The DNS construct of partial matching has nothing to do with this mechanism.

Sorry, that's just plain wrong, he'll get NXDOMAIN.  You're expecting 
CNAMEs to do things that they don't do.  Don't take my word for it -- you 
know all the old DNS weenies better than I do so ask them.  Or see 
RFC1034, section 3.6.2 on page 14, and the algorithm in 4.3.2 on page 24, 
in particular step 3.a.

It wasn't a problem for DKIM because it's exceedingly rare and somewhat 
disreputable to use a CNAME to to point to an MX, but as we've seen it's 
very common for the A record for POP and IMAP servers.

R's,
John

PS: We'll save the other reasons CNAMEs don't do what you want for the 
advanced seminar.

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Tue, 09 Feb 2010 20:09:24 +0100

Dave CROCKER wrote:

> which a

Well, I haven't had enough time to read and think about all messages... Sorry !

IMHO, [2] allows easier handling of reports but [1] is more general.

But I (and surely others) have another requirement. It could be interesting to use this mechanism in 
an active learning context. That means, user can receive the message flagged as "label required". So 
the feedback should include the information : ham/spam.

Regards,

JM

--

---

From: Douglas Otis <[email-masked]>
Date: Tue, 09 Feb 2010 11:26:31 -0800

On 2/9/10 10:34 AM, Dave CROCKER wrote:
> He'll get a TXT record back.  This is nothing but exactly the same 
> mechanism that is used for DKIM and SRV, albeit with a different 
> underscore subdomain.
This overlooks an issue created by SPF having defined TXT records 
without prefix labels to permit wildcard use.  A query for 
_report.mail.btinternet.com IN TXT might obtain an unexpected wildcard 
TXT record.  There is no registry related to disambiguating TXT 
records.  When used for DKIM, cryptography attests validity.    There 
might be a better chance for an SRV label registry of being developed.  
SRV records offers a means to establish redirection, having a similar 
effect as a CNAME.

By using SRV records, a receiving domain controls where reports are to 
be sent.  SRV records even allows for load balancing techniques.

-Doug

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 10 Feb 2010 12:23:05 +0000

--On 9 February 2010 20:09:24 +0100 Jose-Marcio Martins da Cruz 
<[email-masked]> wrote:

>
> But I (and surely others) have another requirement. It could be
> interesting to use this mechanism in an active learning context. That
> means, user can receive the message flagged as "label required". So the
> feedback should include the information : ham/spam.
>

Yes, the content of the report remains to be discussed. If we were able to 
go down the route of labelling the message on the mailstore, I'd like to 
see a rich set of messages available for two way information flow, 
including the following meanings:

The server filter thinks this message is junk.
The server filter thinks this message is not junk.
The MUA filter thinks this message is junk
The MUA filter thinks this message is not junk
The user has asserted that this message is unwanted
The user has asserted that this message is wanted
The user has asserted that this message is reportable

Perhaps probabilities could be associated with filter results, too.

<AGENT> asserts with <LIKELIHOOD> that this message is <JUNK/NOT 
JUNK/PHISH/etc> because <REASON>

Where AGENT might be the userid of the user applying the report, or the 
name of the filter software (eg spamassassin, mail.app, thunderbird).

LIKELIHOOD could be based on a spamassassin score or a bayesian analysis.

REASONs could be filter rules (eg spamassassin hits), free text applied by 
the user, etc.

Thus, the mechanism could be used to give very specific information to 
users, or to operators.

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Wed, 10 Feb 2010 13:33:42 +0100

Hi,

Ian Eiloart wrote:

> Yes, the content of the report remains to be discussed. If we were able 
> to go down the route of labelling the message on the mailstore, I'd like 
> to see a rich set of messages available for two way information flow, 

The filter in the MTA is asking what label the final user assigns to this message.

I'm talking about some way to let the filter in the MTA ask a question to the final user. And the 
report submission could be used to send this information back to the filter in the MTA. This is 
active learning.

This and your meanings were subject of discussion in a dead subgroup of ASRG (filtering, if I 
remember its name).

The content of the report can have some free text space which can be used to add all this additional 
information.

-- 
  ---------------------------------------------------------------
  Jose Marcio MARTINS DA CRUZ           http://j-chkmail.ensmp.fr
  Ecole des Mines de Paris
  60, bd Saint Michel                      75272 - PARIS CEDEX 06
  mailto:[email-masked]