Hello. A few toughts:
Much of today's spam comes direct-to-MX via compromised home machines
on dynamic IP addresses. The dynamic nature of these IP addresses
reduces the effectiveness of DNSbls of compromised machines. The next
step is to pre-emptively block email from *ALL* dynamic addresses. The
problem is that there are so many, that the zones get huge.
I think there is a much stronger reason to avoid trying to block dynamic
addresses: it causes false positives. A well implemented UA that injects
mail
via SMTP (with or without the submission subprotocol) is the "correct"
way to do things given that the 'net was designed for end-to-end
communication.
I would say that the proper way to handle dynamic addresses is by behavior
control and not by outright blocking. Rate limiting comes to mind, as well
as
error counting.
The proposal
[...]
Being able to distinguish the "offical" outbound mail clients for a specific
domain is, however, useful in general. Whether one decides to block or
control incoming connections when they come from another client is an
orthogonal decision.
1) This proposal does *NOT* require new types of DNS records or other
protocols. It can be implemented within the existing structure. AOL
already does this, an example that it can be done.
Yes, but unless that list can be published and retreived automatically, and
kept in sync without human intervention, it has very limited usefulness.
This
means that you would need to define:
a) a standard location where given a domain name 'example.com' you have
a method and exact location where that list can be found. E.g.:
http://example.com/smtp-outbound-servers.xml
Problem: this only work for domain names which have publically
accessible
file serving. Not all domains from which mail could be sent have http
servers,
or even ftp servers for that matter.
b) Some way of delegating. 'us.example.com' may well have different
administrators and mail policies than 'jp.example.com' in addition to
being
on different continents.
Because of (b), you may find that the easiest way to find that location
might
be to put /it/ in DNS (in a TXT record, say). This solves most of (a) since
the
TXT record might point to an URL at some hoster or upstream provider that
does serve files.
c) When you do manage to get your hands on the list, it needs to be in a
stable, documented and machine parsable format. A good idea might be
an XML DTD.
d) How can the system be broken, exploited? What happens if 'evil.com'
points at a dynamic IP on some random ISP? What happens when the
file is broken or otherwise unusable?
Indeed, when you think about it that file might contain lots of useful
metainformation about a domain (abuse address, technical contacts, policy)
related to mail or not. Despite the apparent weaknesses, it might we worth
it
to examine the concept.
-- Marc A. Pelletier
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg