Subject: RE: Does marid-submitter-02 really make sense?

From: "Harry Katz" <[email-masked]>
Date: Mon, 9 Aug 2004 18:02:33 -0700

On Monday, August 09, 2004 5:40 PM Philip Miller wrote:

> Shevek wrote:
> > On Mon, 9 Aug 2004, Harry Katz wrote:
> >>On Monday, August 09, 2004 10:24 AM [email-masked] wrote:
> >>>First, I am not proposing anything here. Not only is 
> SUBMITTER not my 
> >>>idea, I have been quite clear that I am ambivalent about its 
> >>>inclusion in MARID.
> >>>
> >>>Second, the optimization in case 1 isn't a failure case 
> but a success 
> >>>case.
> >>>There may be a throughput improvement in some MTAs if the 
> check can 
> >>>be done sooner. Mind you, I'm not saying there is guaranteed to be 
> >>>such an improvement
> >>>- just that it is a possibility. Actual implementation experience 
> >>>would be needed to tell for sure.
> >>
> >>Ned is exactly correct here.  The purpose of SUBMITTER is to allow 
> >>early (i.e. at 2821-time) verification of the sender's identity, 
> >>namely the PRA.  At the IETF meetings last week there was some 
> >>discussion of whether this would result in bandwidth saving, 
> >>throughput improvement, or no benefit at all.  I tend to 
> think there 
> >>will be modest throughput improvement, but agree with Ned 
> that we need to verify through testing.
> > 
> > This is incorrect. At 2821 time, we know only who the 
> sender CLAIMS to 
> > be via SUBMITTER. It's not until after 2822 time, when we 
> can compare 
> > the SUBMITTER value to the PRA value computed from the 2822 headers 
> > that we have verified the identity of the sender.
> 
> The idea is that the DNS lookup and check can be parallelized 
> with the continuation of the mail transaction, and then the 
> final response to the DATA payload will be sent when the PRA 
> matches the SUBMITTER and the SUBMITTER is allowed by its 
> domain's DNS record.

Sure, that's one possible implementation choice, but not the only one.
The spec recommends rejection if the SUBMITTER value fails the Sender ID
check.  Matching the SUBMITTER value to the 2822 headers is a separate
requirement.

---

From: "Ryan Malayter" <[email-masked]>
Date: Thu, 12 Aug 2004 09:54:14 -0500

[Mark Shewmaker]
> That will happen now, just more indirectly, via IP-based block lists. 

Tell me about it. It's pretty much impossible to get de-listed from
SPEWS if you're a Qwest DS1/DS3 customer, for instance. Whole class Bs
of the Qwest IP space are blacklisted by SPEWS.

This is one of the best things about SPF/MARID - it allows us to base
reputation on the sending domain's behavior, rather than on the
reputation of some large bureaucratic company that won't commit the
resources to police the behavior of their thousands of clients in a
timely fashion. However, the problem with blacklists getting stale or
being incorrect still remains.

Once I tried to do a False-Positive/False-Negative comparison of the
popular IP blacklists, but was unable to get it working properly with my
very rusty C skills.

Has anyone ever seen an effective "reputation system for reputation
systems"? I've seen a few statistical comparisons of DNSBLs, but they
all seem to ignore the most significant item when it comes to spam
filtering: the false-positive percentage. Of course, you have to have a
person manually evaluating whether or not each message *is* spam to get
this data, so perhaps that's why.

Such "reputation system grading" is probably something that is going to
be even more necessary as SPF/MARID grow in popularity. People will need
to know which reputation systems they can trust, right?

Regards,
	Ryan