Always Learning wrote: > Bill Hacker wrote ......... > >> "Real folks" MTA have DNS creds. Botnet WinZombies do not. QED. > > The facts of everyday email receiving is some very large organisations > give out false HELO / EHLO and/or have non-resolving hosts. > > Perhaps it really is time for a SMTP RFC stating that: > > (1) HELO / EHLO must resolve to the IP address of the sending server;
The RFCs' HAVE said that since 'day one' - about twenty years now. > > (2) The sending server (MTA) must have a resolving host name. > The RFC's HAVE said that also and for even longer. Predates smtp, IIRC. Mind - an 'IP Literal' is OK instead of a domain if not 'public facing'. HOWEVER - that is only good for non-public boxen sending in their cron'ed reports, copiers calling for toner, soft-drink machines wanting refilled, etc. .. and justifies special handling on the in-house recipient boxen. Port 24, in our case. DNS doesn't want IP's as the resolution for the PTR RR of *other* IP's. It wants the ability - coupled with 'WHOIS' - to track to a responsible organization or person. smtp was never granted an exemption from that. The *problem* is that smtp RFC's - (Hell ALL RFC's!) rely on a mesh of many. many *other* RFC's to establish the overall networking environment. And those two particular points are not always so obvious in any one given smtp-relevant RFC. The other 'needful' ones are not even always referenced. But dig deep, and find that ... ANY IP-using device offering a public service is supposed to have at least a PTR RR. And that requires a registered <domain>.<tld>. And that leads to a responsible-party-of-record. All that is in 'other-than smtp' RFC's. DNS-relevant, mostly. And those pesky 'generic' PTR RR of connectivity providers? Not wanted for smtp, but they DO have their place. They at least show us the <domain>.<tld> of the ISP w/o a lookup. And they can make it faster for a provider to ID whom was misusing their network at a specific point in time when someone gripes. But smtp just happens to be one of the services where it really *matters* that an IP ALSO resolves, not to a 'generic' adsl.xx.xx.xx.xx.<domain>.<tld> but to an FQDN that can be 'associated' with a mail server in DNS. IOW 'outbound pool' vs 'inbound' vs 'relay' mail servers are fine - so long as each of them that is 'public facing' has some reasonable facsimile of valid credentials. And a means to associate same. - Exim's test of that is both thorough and as forgiving as it can be. Read the source code. It actually researches and builds *lists* of possibilities before it gives up. But it *must* have a valid PTR RR for openers. The HELO to FQDN match, OTOH, often needs a wee bit of slack. Problem there is that it is permissable to assign multiple <domain>.<tld> to one IP, and the critter making the first DNS call may not be able to parse a multiple return that is not in the same order each go. Or gets back only ONE of the several entries each go. > Exim provides excellent tools for rejecting spam but when large > organisations, some operating internationally, can not care less the > dilemma for others is whether to adhere to one's own standards or > succumb to accepting spam, virus and Trojans into the system. > Large organizations can play be the same rules as the rest of us. Or use snail-mail. And smail mail carriers have strict rules ALSO... Not very 'generous in what you accept' there, either. Not a good idea to ship an alarm clock, wires, or battery by post these days.. ;-) > I reject virtually everything not 100% correct. It produces a (so far) > 100% spam free operation. A selection of other people's standards can > be seen on sys.u226.com/t21/t21.php > > Paul. > *Fortunately* - enough of the 'majors' have also toughened-up as to both intercepting zombies heading out of their backside pools toward port 25, AND being tougher about wanting to see a 'useful' PTR RR on incoming outsider arrivals, that we 'purists' are no longer standing against a tide of those 'be generous in what you accept' Sandalista's that created the spam-friendly environment in the first damned place. RFC's for smtp *and applicable relatives* - applied as written long ago, insisting on HELO FQDN match, valid PTR RR and MX or A record, etc - even without strict HELo tests, usingf basically Exim's rDNS will stop nearly all zombies and botnets cold. With decent DNS entries assured, remaining 'now made visible' bad-actors can then be ID'ed. And scalled to account. Unless one lives in the USA, where Congress sold the mass-marketeers a (You too) 'CAN Spam act' for some serious money. Only when someone offers said "Parliament of Whores" (thanks, PJ) a higher price will that POS get repealed. All the spf, DK, DKIM, yadda, yadda, is mere frosting on a cake that wasn't broke in the FIRST place ... if only the players stuck to the rules. WITH those rules, plus SA content scanning, I see about one marginal spam every three days. 'marginal' meaning it is usually a real company, just stoopid or rude about advertising... With same tough ruleset and NO content scanning - about two a day. BFD Bill -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
