3) Require the parameter to be an FQDN and check whether its A record
matches the sender IP.
This will additionally block all senders which don't have an FQDN or
don't know it (which currently seems to be true for a lot of open
proxies, but may change quickly).
I see very little legitimate mail in my log files which doesn't pass
tests 1) to 3). For the few cases which would break on 3), I would
consider it reasonable for the administrator on any legitimate server to
get an FQDN and a matching A record. This is even possible for dynamic
IP addresses via dyndns.net and similar services.
I think test 3 is two steps too far. Suppose I normally send through the
(obiously private/closed) SMTP relay mailer.somecorp.co.uk so I pass
tests 1,2, 3, annd 4 without trouble. The one day mailer.somecorp.co.uk
is horribly dead (teh thames burst its banks and its under 8 feet of water
and mud); what I will want to do is send the mail direct from my desktop
so it can either say "helo tom.somecorp.co.uk" and fail tests 2 & 3 since
that machine has no public IP address, it's behind a firewall which provides
address translation and never under any circumstances passes an incoming
connection request to it or I can say something like
"helo (10.1.1.67) Sorry about the crazy IP, but I'm nasty NAT and DHCP"
and pass test 1 (yes, that extra text after the closing bracket is a
legitimate part of an "address literal") and fail test 2 because 10.1.1.67
is not the translated address that gets to your server, and test 3 because
I've used an address literal instead of an FQDN.
So maybe it would be better to have just two tests:
1) the helo record contains either an FQDN or a an address literal
2) If it contains an FQDN then either the DNS lookup for that FQDN delivers
the sender IP adress, or the reverse lookup for the sender IP address
delivers something with a reasonable relationship to that FQDN; if it
contains
and address literal, either the address part of that literal is the same as
the sender IP or it is in a range which is not allocated for "normal" use.
The disadvantage is that it fails to discriminate against transmissions
which
have the characteristics which you don't like; the advantage is that it
doesn't
com[pound a disaster (in the suggested event of a flood, it might be a life
and
death mater to get the email out).
Of course RMX styule proposals fit in perfectly well with this view - we
just
make all the public addresses used by our NAT system appear in the RMX
records
for somecorp.co.uk. So you could add that test too if some form of RMX-like
proposal were agreed (which would also force people to be a little more
secure
in their mail habits at the same time as improving spam attributability).
Tom
Tom Thomson
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg