At 12:11 PM 1/27/2006 -0500, you wrote:
On Fri, 27 Jan 2006, Julian Mehnle wrote:
> Seriously, M:S:Q does _not_ perform an independent HELO check -- it never
> did and never will. I even documented this in 1.999 RC3. M:S:Q only uses
> the HELO identity if MAIL FROM is empty.
Pymilter doesn't check HELO if MAIL FROM gets SPF pass (real or guessed).
But HELO is checked if MAIL FROM cannot be verified. If there is no
SPF record for the HELO, it checks for (my interpretation of) rfc compliant
HELO (HELO name resolves to connect IP). If HELO cannot be verified,
and there is not a valid PTR either, then the mail is rejected (3 strikes).
I'm planning on adding to my pymilter an SPF check on the HELO name,
*prior* to the MAIL FROM check. The assumption is that if I get a PASS, I
can proceed with a reputation check, and possible whitelisting, but if I
get anything else, it goes the normal route through the spam filter. Is
there any reason this won't work? e.g. are there any legitimate servers
saying "HELO, this is example.com", but having an SPF record under
example.com which does not authorize that server?
Typographical errors can occur, of course, but I'm assuming these would be
corrected by any sender that takes the trouble to publish an SPF
record. My concern is that I don't want to violate sender policy by
"re-interpreting" an SPF record in a way that might not be intended by the
sender.
We get 10000 - 40000 connection attempts a day, most of which flunk
the 3 strikes test. Occasionally, there is a "legitimate" sender with a
really
badly configured mail server. For those cases, if the postmaster won't
fix their server ("I've been using names like 'JUPITER' for HELO
for 10 years without a problem. You obviously don't know what you're
talking about."), we enter a local SPF record for them.
Keeping up with changes in these local records seems like a big burden. If
the sender doesn't provide a way to automatically keep the information up
to date, my preference would be to treat them the same as any other
uncooperative sender - filter, filter, filter.
The only "receiver policy" I will enforce is rejecting IPs that are
spamming so heavily it puts too great a burden on my server. Conflicts
over other rejects should be between the sender and individual recipients.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: macquigg at box67.com * *
* President, Open-Mail dot org phone: USA 520-721-4583 * * *
* Admin, Box67 dot com * * *
* 9320 East Mikelyn Lane * * *
* http://purl.net/macquigg Tucson, Arizona 85710 *
************************************************************ *
-------
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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com