Rich Felker
Spam defense tip for folks self-hosting email: the #1 performing rule I have (accounts for ~75% of blocked messages) is rejecting forged EHLO hostname.
That is, client greeting us with EHLO followed by a hostname that does not resolve to the IP address they're sending from.
It's dead simple but super effective. Does need a few allowlist exceptions for known broken senders, most notably Microsoft.
Rich Felker
The second best performing rule (or set of rules) is rejecting malformed non-ASCII character encoding (omitting necessary MIME headers to declare charset and transfer encoding, failure to encode characters in headers right, etc.)
This catches a LOT of Chinese and Japanese spam. In theory there might be "legitimate" clients that send equally broken mail, but it wouldn't be readable without knowing what encoding they intended it to be interpreted as, anyway.
Rich Felker
@hyc Yeah, I was never a fan of any measures that are hostile to folks self-hosting their email, so no to that one.
In practice, the spammers on dynamic IPs usually can't manage to lookup their own hostnames correctly to put in the EHLO line, so just checking that the EHLO is valid blocks them anyway without blocking self-hosting folks who don't have access to better IPs.
Howard Chu @ Symas
@dalias my favorite was always hosts whose IP address is encoded in their DNS name. I used to just flat reject them but now I only greylist them because more subscription mailers are using dynamic hosts for sending.
Howard Chu @ Symas
@dalias if you're really self-hosting your email you should have an actual domain name of your own though, and it should resolve both forward and backward.
Rich Felker
@hyc Resolving forward only takes a domain name. Resolving backward requires an IP address you sufficiently own for someone to delegate PTR authority to you - something that can be out of reach for most people.
Bitslingers-R-Us
@dalias Ages ago, I twisted my brain enough to learn Sendmail rules and came up with two HELO / EHLO checks: one which requires that the HELO / EHLO name resolves to the connecting IP(v6), and that the PTR for that address also resolves to the same address, and one that’s not as aggressive and just makes sure that the HELO / EHLO name resolves in DNS.
Checking that the PTR name resolves to the same address as the PTR is beyond Microsoft. I think they’re not allowed to have O’Reilly animal books. They really take “not invented here” seriously, and considering they haven’t invented shit, nothing of theirs works properly.
LOCAL_RULESETS Scheck_mail Kcheckdns dns -R A Kcheckv6 dns -R AAAA Kcheckptr dns -R PTR FH /etc/mail/access # require_dns.m4, 9-November-2003, John Klos (jklos@netbsd.org) # Updated 6-January-2007 # Checks that HELO IP literal matches connecting machine, and # checks that HELO domain name resolves (but not necessarily back # to the connecting server), and that it isn't our name. # This HELO checking is what should be done, anyway; syntactically # invalid HELOs are allowed to be rejected. Checking whether a # HELO hostname resolves is my lazy way of checking the syntax. # localhost (real address, not HELO localhost) is always Ok. R$* $: $&{client_addr} R127.0.0.1 $@ RIPv6:::1 $@ RIPv6:0:0:0:0:0:0:0:1 $@ # Skip checking if connection is authenticated R$* $: <$&{auth_type}> R<PLAIN> $@ # Reject addresses with no / broken reverse DNS R$* $: < $&{client_resolve} > R<TEMP> $#TEMP $@ 4.4.0 $: "450 Relaying temporarily denied. Cannot resolve PTR record for " $&{client_addr} R<FORGED> $#error $@ 5.7.1 $: "550 Relaying denied. PTR likely forged " $&{client_name} R<FAIL> $#error $@ 5.7.1 $: "550 Relaying denied. PTR lookup failed " $&{client_name} # Reject our own names. Anything that's in /etc/mail/access or # /etc/mail/local-host-names should not match any HELO name. R$* $: $&s Rlocalhost $#error $@ 5.1.8 $: "550 Access denied. You are not obviously not localhost." R$=w $#error $@ 5.1.8 $: "550 Access denied. You are not "$&s"." R$=H $#error $@ 5.1.8 $: "550 Access denied (access file). You are not "$&s"." # Reject common domain names which all use proper HELO strings. Ryahoo.com $#error $@ 5.1.8 $: "550 Access denied. You are not "$&s"." Rjuno.com $#error $@ 5.1.8 $: "550 Access denied. You are not "$&s"." Rgoogle.com $#error $@ 5.1.8 $: "550 Access denied. You are not "$&s"." Routlook.com $#error $@ 5.1.8 $: "550 Access denied. You are not "$&s"." Rhotmail.com $#error $@ 5.1.8 $: "550 Access denied. You are not "$&s"." Rmsn.com $#error $@ 5.1.8 $: "550 Access denied. You are not "$&s"." # This test checks if the HELO string either matches or is the last part of # the PTR record for services such as Hotmail and Gmail. R$* $: <$&{client_name}> <$&{client_resolve}> R<$*$&s> <OK> $@ # Skip checking if connection is authenticated R$* $: <$&{auth_type}> R<PLAIN> $@ # These rules assume that all will be OK if: # HELO [IP address] matches [{client_addr}] or # HELO [IPv6:IPv6 address] matches [{client_addr}] # Or, if neither of the above, that the HELO string must be a FQDN (primary # host name) as per the RFCs and therefore should resolve. Non-matching # [IP address] or [IPv6:IPv6 address] do not resolve as FQDN and fail below. R$* $: $&s R [$&{client_addr}] $@ # Stick the connecting IP address into the workspace; if it's an IPv6 address, # replace it with the IPv6 address of the AAAA HELO lookup. If it matches # the connecting IP, it's Ok. R$* $: $&{client_addr} RIPv6:$+ $: <$( checkv6 $&s $: FAIL $)>V6 R<$&{client_addr}>V6 $@ # Stick the IP address of the A HELO lookup into the workspace. Fail # if the lookup fails. R$* $: <$( checkdns $&s $: FAIL $)>V4 R<FAIL>V4 $#error $@ 4.1.8 $: "550 Access denied. HELO does not resolve. (HELO " $&s ")" R<$&{client_addr}>V4 $@
Rich Felker
@AnachronistJohn Uhg, what is printing a v6 in non-canonical form??
Bitslingers-R-Us
@dalias Holy cow! Remember juno.com?
I have to check if RIPv6:$+ $: <$( checkv6 $&s $: FAIL $)>V6 does what I expect it to, because I got something like this not long ago:
Access denied. HELO name does not point to connecting server (CH1PR05CU001.outbound.protection.outlook.com != IPv6:2a01:111:f403:c105:0:0:0:1)I think I was expecting canonicalization of the IPv6 address.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.