Jim Ramsay <[EMAIL PROTECTED]> writes:
or better yet, just be reading the Received-SPF header on a server whose MTA implements SPF.
This won't be as useful for spam blocking because spam won't contain a Received-SPF header. It's probably only useful for "whitelisting" messages relayed by an SPF-aware SMTP receiver ("pass").
I think it should... Spam coming through an MTA should be processed like any other email coming through that same MTA... and an SPF-enabled MTA will add a "Received-SPF" header according to the following criteria for all mail, according to http://spf.pobox.com/newheader.html:
pass - The client mailserver matches the published SPF record for the email address domain. You can be reasonably sure that the address is not forged. In my case, I'm going to let this through unchallenged.
fail - The client mailserver did NOT match the published SPF record for the domain, so we know the address is forged. (Some SMTP servers will drop these and not tag them). In my case I'll drop it, maybe even at the SMTP level. I'll probably wait and see how this works, though.
unknown - There was no SPF record for the email domain, so no check was made.
error - Something went wrong.
I think spam should be handled exactly the same, though theoretically most of it would come through "unknown" and the rest would probably be "fail". If any comes in "pass" then you can blacklist that mailhost and save everyone from them.
-- Jim Ramsay
_________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
