[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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@xxxxxxxxxxxxx <mailto:seansun@xxxxxxxxxxxxx>) 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@xxxxxxxxx> 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.