Actually that third entry isn't necessary either; the machine needs to identify itself as a valid DNS name, but not necessarily as a name that matches the originating IP address.

This becomes important for multi-homed machines or machines with multiple IP addresses each of which may be used for originating traffic. Heck, maybe even IP4 and IP6 with different DNS names for each address. In these instances the sending machine can not always guarantee that the HELO (or EHLO) value matches the originating IP address.

Any receiving machine that requires the HELO name matches the IP address is broken. The receiving machine may validate that the DNS name provide is valid (many home machines just use their local hostname, and so they get rejected; drop a lot of spam that way!) but it should not attempt to match that to the IP address.

Now you might say "the sending machine can send a HELO value that matches the IP address" but:
1) this doesn't happen in real life. sendmail,postfix etc use the same value no matter what IP address you talk on
2) this value is used for simple "loopback" detection. If I'm called "foo.bar" and I connect to a machine that identifies itself as "foo.bar" then I can immediately abort; I'm talking to myself!

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

My mail acceptance rules are currently:

- HELO is required and logged, but it is not checked for legitimacy (false positive rate too high).
- Envelope sender must have a valid FQDN which must exist
- Envelope recipient must have a valid FQDN which must exist and must be a local destination
- The sending server must not be in an internal DNSBL or a handful of external *BLs[1], and a DNS query for its IP address must return a hostname which, when queried, returns the IP address. A handful of exceptions exist.

[1] These include one which blocks all domains registered within the past 5 days.

A couple important takeaways from this:

- I cannot reject based on bad HELO without rejecting a lot of valid mail.
- I cannot reject outright on forward/reverse DNS failure: I must defer due to the possibility of transient errors, and even with that, I have exceptions for notifications from $bank, my cellphone carrier's SMS-to-email gateways, the Department of Education, etc.

Obviously, others may have more restrictive policies and/or use scoring to divert messages to a spambucket that I would otherwise accept (indeed, so do I), but this is as good as I can do without losing legitimate mail.

So, don't sweat the actual hostname used (I send out as framboise.hoopycat.com), nor the contents of HELO (the Linode threshold alert e-mail I just got was sent from mail.linode.com, which HELO'd as "www.linode.com"). Just make sure they're set to something and your message will make it to the next level of validation.

It probably won't make it through the next level of validation, of course, but that's mostly because the average e-mail I receive is trying to sell me Canadian pills to enlarge my national lottery's late Minister of Finance's free iPhone 5.

smtpd_helo_required = yes

#smtpd_helo_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/heloaccess, reject_invalid_hostname, reject_non_fqdn_hostname

smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain, permit_mynetworks

smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks,reject_unauth_destination, permit

smtpd_client_restrictions = check_client_access cidr:/etc/postfix/access,
                            permit_mynetworks,
                            reject_rbl_client <redacted>,
                            warn_if_reject reject_rbl_client bafrica_asia_south-america.<redacted>.geobl.spameatingmonkey.net,
                            reject_rbl_client bl.spameatingmonkey.net,
                            reject_rbl_client zen.spamhaus.org,
                            reject_rhsbl_sender urired.spameatingmonkey.net,
                            reject_rhsbl_client urired.spameatingmonkey.net, 
                            reject_rhsbl_sender fresh.spameatingmonkey.net,
                            reject_rhsbl_client fresh.spameatingmonkey.net,
                            reject_rbl_client bl.ipv6.spameatingmonkey.net,
                            defer_if_reject reject_unknown_client_hostname,
                            permit

_________________

/* TODO: need to add signature to posts */

I used to have complex rules, but got bored of maintaining whitelists 'cos various companies (eg Banks!) can't run an infrastructure properly. *sigh*

Currently my rules are:

smtpd_restriction_classes =
        sweh_restrictions
smtpd_recipient_restrictions =
        reject_unknown_sender_domain,
        check_recipient_access hash:/etc/postfix/recipient,
        permit_mynetworks,
        reject_unauth_destination
sweh_restrictions =
        reject_unauth_pipelining,
        check_sender_access hash:/etc/postfix/sweh/sender,
        reject_rbl_client zen.spamhaus.org,
        reject_non_fqdn_sender,
        reject_non_fqdn_hostname,
        permit

The "recipient" hash just has "my_domain sweh_restrictions" so that mail sent my domain runs the extra checks; mail not sent to my domain will skip them and fail the unauth_destination check.

The "sender" hash is a white/black list so I can short-circuit deny morons, or whitelist people that would otherwise fail.
eg a blacklist and a whitelist entry

fortunoff@news.fortunoff.com 554 Fuck off spammers - see if I spend money with you again!
list.theregister.co.uk  reject_unauth_destination,permit

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

This suggests a rule of thumb: Make your e-mail appear less dodgy and suspicious than e-mails from a legitimate bank, and you should be alright.

Also, be sure to add stmtnotifyacct@mgate218.bancorpfb.bulkmails0lutns4u.biz to your address book!