At 03:30 PM 1/29/2007 -0500, Stuart D. Gathman wrote:
On Mon, 29 Jan 2007, David MacQuigg wrote:
> There might be a way to do this in SPF without "zone cuts" or "tree
> walking". Of course, it would have been nice if SMTP had an option to
> provide an Identity (domain name) separate from the hostname, maybe with a
> syntax like HELO hostname(_at_)domain, but this will never happen. It might
be
> possible with an SPF record, however, to have an option like op=helo, and
> have that mean - you can use this record to authenticate any HELO name
> *ending* in the domain name of the SPF record.
rr.com IN TXT "v=spf1 ptr -all"
Connect from foo.bar.rr.com:
HELO rr.com ; passes HELO SPF
Connect from baz.bat.rr.com:
HELO rr.com ; passes HELO SPF
You are right, that goes against the spirit (but not the letter) of RFC2821.
The record above conflicts with the existing record for rr.com. Also, it
is very unlikely they will agree to change their current practice of using
a full hostname in their HELO. This is one of those things where we cannot
expect the world to change.
We do PTR checks as part of our fallback DNShunt(), but I really hate to
make them a primary means of authentication, (for reasons of efficiency and
DoS avoidance, as discussed earlier). Our message to senders is - if you
want to use our Registry, please do it right. Publish an _auth record,
telling us what authentication methods you offer, and what addresses you
allow to say HELO for your domain.
That's not a lot to ask of any legitimate domain wanting to operate a
Public Mail Server. Of course, if they are happy with the reputation they
are accumulating using our default Registry records, they need not make
even that small effort. And if our service works as well with only default
records as I am seeing in my initial tests, then at last we have a system
that has no "chicken-and-egg" hurdles to overcome.
I really have not had any problems using validated HELO names (either
via SPF or via matching the connect IP) for reputation. Even a large
ISP has only a few dozen outgoing SMTP servers, and they accumlate reputation
on even a single server quite nicely.
Cool. I'm seeing the same thing as to the reliability of HELO names for
legitimate senders. Of course, that only means that spammers have not yet
gotten around to forging HELO names. I'm not about to get dependent on
HELO names until I'm convinced the authentication of those names is rock solid.
To recap, I am currently choosing the id to assign reputation to as follows:
if SPF is PASS
domain:SPF
elif bestguess is PASS
domain:GUESS
elif HELO is PASS or matches IP or bestguess
domain:HELO
elif SPF is NEUTRAL
domain:NEUTRAL
elif SPF is SOFTFAIL
domain:SOFTFAIL
elif valid rDNS (IP owner authorizes):
1.2.3.4:IP
else
reject - no id
I used to have to manually set SPF policy to reject on neutral for AOL,
for instance. But how, with pygossip, it is all automatic. If a
lot of spam comes in as aol.com:NEUTRAL, then after about 20 messages
the system starts rejecting on neutral for aol.com. A lot of spam
come in with ebay.com:SOFTFAIL? After two dozen spams, reject on
softfail for ebay.com is automatic. A very maintenance free system.
Spam training occurs via honeypots. Ham training occurs via
auto-whitelisting.
All users have to do is look at their quarantine occasionally. There are
very few messages in quarantine any more thanks to pygossip reputation.
Is there any way we can digest this information to an overall rating for
each domain? We could include a "G1" service rating in our Registry
records (G for Gossip, and this is the first service name starting with G).
Are you seeing substantial difference between say aol.com and
comcast.net? Can you quantify that difference?
-- Dave
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735