At 5:34 PM +0200 2003/08/29, Peter J. Holzer wrote:
1) Formal correctness.
RFC 2821 specifies that the parameter must be an FQDN or an address
literal. So you can check against regexps or a grammar.
This will disallow unqualified host names and random garbage.
Unqualified host names are often (legitimately) used by broken MUAs.
I think I have also seen it from misconfigured Exchange servers.
Some viruses/worms (Sobig) and some spammer software also uses
unqualified
host names - this would be blocked.
Many hosts in the world are configured (misconfigured?) to have
unqualified hostnames. Some sites even have an explicit policy that
all hostnames will be unqualified.
2) Check whether the parameter corresponds to the sender IP address.
I.e., if the parameter is an FQDN, look up its A record(s) and
compare to the sender IP, if it is an address literal, compare it to
the sender IP.
This would in addition catch all the software which lies about its
own address. Examples are again MUAs (at least some use either the
server address or the domain name of the sender) and lots of spammer
software which sends "HELO yahoo.com" or similar.
I have over a dozen different e-mail addresses that I use. Only
one of them might potentially correspond to the server that I use
over an ssh tunnel as my outbound mail relay.
If I were to host my own outbound mail relay here in the house,
because I am behind a NAT you might see my server identify itself as
10.0.1.5, when the real external IP address is something completely
different.
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).
This would require a change to RFC 2821. Moreover, it would
break anyone who has an IP address assigned to them (maybe in PI
space), but does not necessarily have an FQDN. See above items 1 & 2.
4) Require the parameter to be an FQDN and check whether the PTR record
of the sender IP matches the parameter.
This will block all addresses for which rDNS isn't available, and
those for which rDNS gives a different name than the "canonical"
name of the host. This includes lots of cable/dsl customers.
And lots of customers or service providers that run their own
mail servers on valid public IP space, but who don't properly
understand the concept of reverse DNS or how to implement it properly.
I'm perfectly happy to mention names of specific individuals
and/or providers that I have personally encountered, if anyone wants.
I'd prefer to keep this discussion above the level of name-calling,
however.
I also think that rejecting mail because it fails a single test (like no
rDNS record or being listed in a single BL) is not good practice (I am
still guilty of that, because that's how sendmail handles BLs, but I am
trying to move to more robust schemes without a single point of
failure).
Agreed. A multivariate analysis should be applied before taking
such a decision.
So for a BCP document I would recommend:
1) Combine different tests (for example by summing scores like
SpamAssassin does) and reject only if some threshold is exceeded.
Agreed.
2) Of the 4 tests I outlined, give the first 3 a high score, and the
fourth a low to medium score.
The benefits and drawbacks of each specific criteria should be
discussed, with recommendations for higher or lower score values,
based on expected probability of occurrence and probabilities and
costs of false positive and false negative matches.
--
Brad Knowles, <brad(_dot_)knowles(_at_)skynet(_dot_)be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg