Re: User experience; RHSBLs; Strong From: check seems possible

> RHSBLs better than what we have now? 
http://spf.pobox.com/faq.html#churn answers that question.
Here's my response:
They seem no better than IPBLs (like the RBL). The countermeasures apply 
equally to IPBLs.
The same pressure that SPEWS, for example, applies to ISPs would be 
applied to registrars. Except I know of no registrar that is cooperative 
and supports SRS, so no one would actually use this hypothetical 
registrarBL. So we start from a worse position. (Godaddy is cooperative, 
but does not and has no plans to support SRS, et. al. in their DNS 
tools, even though they advertise "Total DNS Control", so I have to use 
someone else's DNS servers.)
Interesting that the sendmail press release mentions one Sean Sundwall 
(seansun(_at_)microsoft(_dot_)com <mailto:seansun(_at_)microsoft(_dot_)com>) as behind C-ID, 
but he's never been heard from here.

On 4/10/04 3:35 PM, Doug Royer sent forth electrons to convey:

> Matthew Elvey wrote:
>
> > Doug Royer allegedly said:
> > >Benefit - saves time by allowing automated tools to track spam sources.
> >
> > ><I can write tools that always get contact information given a 
> > domain name, but can't given an IP. \
>
> > I believe that's false.  Both ARIN et. al. info and domain info is 
> > fairly often bogus.
>
> Thank for quoting me accurately. Yes, I  can write such a tool :-)
>
> I never said that sometimes some of the information is a lie.
Right, what you said was true; oops-I read the word "valid" into the 
sentence, even though it wasn't there. 
But my point is that it doesn't allow automated tools that aren't 
already out there.
> > Registrars ignore blatantly false info in both, unless there's been a 
> > recent change I'm not aware of.
> > So I don't believe switching from one to the other is likely to to be 
> > a benefit. 
>
> Would you agree that it allows tracking to the spam source of an  
> infected machine
> where the owner is honest?
And do a better job than IP or other schemes, e.g. Spamcop.net?  No... 
well actually:
In the case of a small organization with its own domain, yes it is 
likely to help some.
The domain info is likely to be accurate, so IF the organization has an 
LMAP record, then its likely to help.
Otherwise, spamcop.net (and scripts that do roughly what it does) do as 
good a job already - for consumer ISPs, .edu, large organizations the 
info is probably already about as accurate, no?
On 4/10/04 9:32 PM, Alan DeKok sent forth electrons to convey:

> Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:
>  
>
> ...
>
> > I think the folks who just want to protect HELO or MAIL FROM have
> > failed to explain why From: is not feasible to protect.
> >    
>  Messages get forwarded by third parties (e.g.this mailing list).
> The MTA/DNS of the "From:" domain doesn't know who in that domain has
> subscribed to what mailing list.  And it's impractical to distribute
> that information outside of the mailing list.
>  
Without SRS/verp, MAIL FROM has the same problem, to a lesser extent.
With SRS, a From: check that failed the initial lookup could look in the 
MAIL FROM to see if the domain in the From: was there.
If it was, then we can conclude that the From: is valid! (with the same 
confidence that we know the remailer is not a spam source because an SPF 
test that includes blacklist checking has been passed). 
If the remailer is a spam source, we would have blacklisted its domain, 
so it's reasonable to put some trust in the SRS MAIL FROM.
There's still the problem of mailing lists such as this one which don't 
need to implement SRS in an SPF world because they change the MAIL FROM, 
but leave the From: alone.   Perhaps a whitelist of machines running 
mailing lists is necessary.  Perhaps RHSBLs for SPF could be 
particularly sensitive to spam that looks like it's from a mailing list, 
and From: checks could be allowed to fail for such email.
>  This issue highlights more implicit assumptions and field
> overloading in SMTP.
>
>  Alan DeKok.
>
>