On Wed, 21 Apr 2004, Meng Weng Wong wrote:
On Tue, Apr 20, 2004 at 01:19:26AM -0400, April Lorenzen wrote:
|
| This document offers a recommended standardized FQDN (Fully Qualified
| Domain Name) naming convention pattern for servers used to send outbound
| internet email. The purpose is to allow inbound internet email servers
| to recognize outbound email servers designated as authorized or
| unauthorized by those in control of DNS for the sending server IP addresses.
This is an interesting alternative approach to the MTAMark space.
But its not MTAMark at all, this is more like LMAP proposals actually.
It realies on the host first looking up domain in ehlo or mail-from and
checking if that one lists anything regarding inaddr record. That means
that zombies will work just fine, they just have to use domains that have
no FQDN or other records (and no - don't put much hope that in 1 year,
50% of the domains would have these records or even 25% - if things go
REALLY well - you might hope for 10% number). But zombie use is continuing
and increasing rapidly and unless LMAP proposals which try to address forging
issues, the INADDR based records will actually address this issue directly.
On that note, I would like to mention that our single most successful
antispam rule at Pobox is "does it look like a broadband host".
Correct - but without ISP telling you what it is, you're making a "guess".
Which might be correct or might be wrong. If people here follow nanog, you
might have noticed a recent thread there regarding how sorbs sometimes
makes mistakes about it, which pisses ISPs off. Its better to just let
ISPs tell you what kind of space it is.
We can tell if a machine is a broadband host simply by checking if the
hostnam contains the IP address. Broadband machines usually PTR to
something like
6535215hfc174.tampabay.rr.com
This does not tell you that its broadband, you're making this assumption
not because of 653... but because its "tampabay.rr.com" because you know
"rr.com" is large cable provider.
c-24-8-173-129.client.comcast.net
Same as above - you know name "comcast.net"
In a way, this kind of hostnaming scheme is analogous to the .mxout. and
MTAMark concepts, except that it's already in place and doesn't need
much new work. You just have to write a handful of heuristics that
capture most of the broadband conventions in use today :)
Except forcing policy record as part of PTR convention is not the best idea,
its totally different things and specific rdns records even for broadband
connections might be needed in some cases. Its better to have policy about
MTA connectivity from the ip as a separate record under INADDR tree.
In the future I plan to implement a very simple antispam algorithm that
works like this:
1) is the MAIL FROM in an RHSBL? If yes, reject.
2) does SPF pass? If yes, accept.
3) does it look like a broadband host? If yes, reject.
I would prefer it be like this:
1. Check incoming ip (before establishing SMTP connection) and not just do
PTR request but "*" request on reverse-ip.IN-ADDR.ARPA which should provide
any type of record for that ip.
a. If ip is in blacklist you trust (all MTA admins define what they trust
on their own, can be nothing) - then reject the connection
b. If there is record there that indicates there should NEVER BE any
computer on that ip or NEVER BE any SMTP connection from that ip,
then reject the connection (never be might be ip range not yes
assigned. On this point I note that Rob Seastrom in recent ARIN
meeting informerly proposed an interesting idea of putting wildcard
"A" record in in-addr tree as easy way to detect bogon ip space -
then anything that has not yet been assigned by RIR would have
automatic default no-connect record. I do not support wildcard "A"
records, but would support some other type of wildcard record,
specifically designed for purposes of providing these kind of
policy information
c. If there was a policy record in INADDR tree but it was not that there
should NEVER be smtp connection from that ip, then record that policy
record and proceed futher with SMTP connection. Note that other
policy record in INADDR might say that its a broadband or some other
type of end-user machine which can sometimes open SMTP connection,
but that its usually rare as its direct end-user or it might say
that its mail server machine which will establish SMTP connections
very often as part of its operations
2. Proceed with establishing SMTP connection if there was no direct REJECT
policy based on just ip itself. Proceed first with EHLO part.
If there is mail policy record on the domain specific in EHLO then:
a. If that policy record specifically says that ip address that
establishing the connection is the one used for that domain and
INADDR policy record says that its end-user or mail server, then
accept the connection
b. If however INADDR policy record is end-user or none at all and EHLO
policy record does not match then reject connection.
c. If there is no EHLO domain policy record, then proceed to #3
Note: Optionally MTA may also choose to reject connection if there
is end-user INADDR policy record and there is no EHLO
domain policy record.
3. If there no reject during EHLO step, then proceed to MAIL-FROM step.
Check policy record for domain listed in MAIL-FROM. If that record specifies
which ip address(es) can send email claiming to be from that domain, then
check if the ip address matches.
a. If MAIL-FROM policy record matches incoming ip, proceed futher
b. If MAIL-FROM policy does not match but INADDR record indicates that
its a mail server, then proceed and consider this to be a forwarding
mail server. However note that records does not match and add this
information as part of email tracking header
4. Additional step to check for known spammers - check domain entered
in EHLO and mail from and see if it matches well known spammer from
list provided by trusted anti-spam authority (similar to ip-based black
lists, trusted lists or none-at-all chosen by mail admin) then reject
at this point, otherwise proceed and complete SMTP connection
Linux hobbyists who send mail legitimately from their home machines
controls their virtual domain; the onus is on them to publish SPF
accordingly. It's something they can proactively do, and don't mind
doing.
I agree with above as I already posted about it before too.
Spammers can publish SPF (and some already do, as expected) but because
they (in theory) show up on RHSBLs, that doesn't help them.
Spammers would change to getting new domains, then possibly setting up
subdomains there and whitelist very large ip blocks or entire net as
acceptable sources. This is not good unless we forece then to whitelist
specific zombies they used individually - then we also have record of
intent for unuathorized use of somebody elses computer by specific spammer
prior to them even using it (this is very usefull in tracking such abuse
and futher legal cases).
Zombie machines that forge MAIL FROM get blocked by #3.
Zombie machines would not forge mail-from unless spammers are using them
and setup specific domains for that. Spammers would then most likely not
enter any SPF or any other similar LMAP proposal records at all or at best
enter records that whitelist entire net or close to it (entire cable provider)
to make it easier for them. As such LMAP based on mail-from or ehlo will
not do much to combat zombie spam. LMAP does help to combat phishing spam
variants (which does often come from zombie, but its only a small subset).
Viruses unfortunetly sometimes come as if directly from user of the computer
(easy to check outlook mailbox settings). If its known for certain that
this user will ALWAYS use broadband ISP mail server (i.e. he's using standard
user(_at_)attbi(_dot_)com email for example - fyi: yes I know attbi is no more
that
is why I used them as example) then that large isp can specify in its EHLO
policies regarding this and only indicate their main mail server relays -
this would allow for connection from ips marked for broadband end-user to
be rejected. Those of the users that do need to send email directly from
their broadband computer (but use their user(_at_)attbi(_dot_)com email
address) can
do it by buying a domain for themselve and setting that domain with
appropriate EHLO policy whitelisting their home connection and then using
that domain in EHLO when initiating SMTP from their dialup connection).
Since number of such users will be rare, the viruses would usually not be
able to use this backdoor.
In Summary - as you probably guess I advocate combining the proposals and
various identity verification into more complete system being used
together. Each one proposal has its problems and does not achieve all
results on its own but when done as combination, I think they may prove
very usefull. As secondary I also like to see unified DNS record policy
syntax for convinience of administrators and programs that setup these
records. This problem was supposed to be address by LMAP group in ASRG but
it failed to achive consensus. SPF did good work in this area, however -
thank you Meng! (eventhough I continue to be against using TXT for this
policy mechanism, we need separate dns field dedicated to advertisement
of policy mechanisms through dns).
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net