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
