Jim Ramsay <[EMAIL PROTECTED]> writes:
Fail: the message does not meet a domain's definition of legitimacy. MTAs MAY reject the message using a permanent failure reply code. (Code 550 is RECOMMENDED. See RFC2821 [11] section 7.1)
As a practical matter though, I don't expect many sites to allow such a message through, and just add a ``here look, this message is a forgery!'' stamp to it.
Until I'm sure that the SPF implementation I'm using works reasonably well (I'm not really sure how to verify this yet!) I'll be looking at everything, fail or not. Once I'm satisfied I'll be dropping it all, but I do agree that it doesn't make sense to keep known forgeries. It certainly doesn't make sense to challenge them either :)
MAY is not MUST - so this may come through sometimes, depending on the SMTP implementation, in which case I think TMDA SHOULD drop it.
True, so we should document this because the possibility exists.
Exarcly.
BTW, are you just using 'headers' or 'headers-file' in your incoming filter to implement SPF checking?
Since I just got qpsmtpd working today and checking for SPF, I haven't implemented this yet. But since I've only got two things to check for (with different actions for each), and only one other 'headers' match in my entire incoming filter, I don't think I need to use a headers-file.
I have just put the following near the top of my incoming filter:
headers "Received-SPF: pass" accept headers "Received-SPF: fail" hold
Though I'll soon change that second one to drop. (Or more properly start dropping at the MTA level since I can control that myself)
Also, I am already doing a crude SPF-like thing in Postfix. If the message is from [EMAIL PROTECTED], the connection must also be from hotmail.com, or I reject it. I do this for all of the common mail providers like yahoo.*, aol.com, etc. This has been 100% effective for me and reduced my spam influx tremendously. It's not as elegant as SPF of course because it doesn't accommodate sites which relay mail from a server in a different domain, and the list of domains to check must be hardcoded.
I think SPF does something moderately like this too for sites who have not yet added SPF records to their domains - check out the "Best Guess" section in the FAQ (http://spf.pobox.com/faq.html) - Looks like it does this:
- Check the ip address of the A record for the host-part of the envelope sender. If that IP address and the connecting client's IP match within the netmask 255.255.255.0, consider it a "pass".
- If that didn't work, check all MX records for that domain, and match each of those to the client IP within the netmask 255.255.255.0 as well to consider it a "pass"
- Else mark it as unknown
SPF's way is more likely to increase correct "pass" matches since it considers MX records too and is more flexible (due to the subnet matching), and would maybe reduce the number of false positives that *could* be generated with your way. Because of this it probably wouldn't eliminate as much real spam as yours, and since you're limiting your checks to the big free domains which really only do webmail sending anyway, it's probably pretty safe. Maybe I'll write a qpsmtpd plugin to do this too :)
qpsmtpd has some other neat tricks as plugins that I hadn't thought of:
- Reject any email from a "yahoo.com" address if the client uses an SMTP HELO yahoo.com (as real yahoo servers never use just "yahoo.com, but a real SMTP server)
- Ensure the sender's email domain is resolvable (old trick, but qmail-smtpd didn't do this)
- Check a rhsbl like dsn.rfc-ignorant.org
- Disconnect if the client does too many (# configurable) unknown SMTP commands
- Check for an "Early Talker" that starts sending data before the server says Hello
-- Jim Ramsay
_________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
