Paul Smith wrote:
The difficult bits, at the moment, are: (1) knowing that the message
has come from a server authorized to transfer mail on behalf of
hotmail.com, and (2) if it's gone through multi-hop servers, checking
that it's not been faked in that part of the process.
Problem (1) could be solved by having an SMTP extension where the MX
servers for a domain can be asked if a particular IP address is
allowed to send mail on behalf of that domain.
Problem (2) is more tricky, but it would only be needed where mail
from the sender's domain doesn't come directly to you, but goes
through other (untrusted) relays in between.
I've been noodling on this and I think that a DNS approach will work,
although there are some costs associated with this approach that need to
be recognized first.
First off, using an MX RR for this is inappropriate, since MX defines
inbound relays, but many organizations use different servers for their
inbound and outbound relay functions. Some other RR has to be defined for
this to work with those organizations. However, it may be feasible to
specify that an MX RRset MAY be used if this other RR is not provided,
since this would include the 99% common case scenario where the inbound
and outbound relays are identical.
As for which RR to use, draft-church-dns-mail-sender-01.txt already
describes an MS (Mail Sender) RR for this purpose, and it would be just as
usable as anything else.
The principle problem with the use of these kinds of RRs is that they add
more RRs to the owner domain name. This contributes to a problem where the
DNS answer set overflows the response message, especially when queries are
issued for ALL RRs associated with the domain name (as is the wont with
Sendmail). For example, if the domain name already has an SOA, A, and
multiple NS and MX RRs defined, then it is already somewhat likely that
the 512 octet limit on the DNS message will be exceeded (look at
hotmail.com, with 14 MX RRs it overflows responses for just MX, nevermind
queries for ALL).
Another related problem here -- and the real concern for overflows -- is
that new RRs cannot use compression, since downstream caches have no
knowledge of the RRdata structure. They don't know if the compression
pointer is actually a compression pointer or if it is a numeric value or
what, so the result is that no new RRs can have compression. This is
almost guaranteed to trigger overflow even in relatively small sets.
Although from a hypertechnical perspective this is not a problem (the DNS
protocol defines the proper behavior), in practical terms this is an issue
to worry about, since DNS overflow requires at a minimum that the client
reissue the query over TCP, but not all DNS systems perform this fallback
processing. Furthermore, TCP DNS queries incur higher penalties on busy
servers, and they introduce a minimum of four round-trip times (counting
the original UDP failure) for every lookup. Adding a bunch of MS RRs will
absolutely result in more zones overflowing DNS answer sets and this will
result in more incomplete MX answer sets when fallback processing doesn't
take place, and performance problems when TCP fallback processing does
take place.
Another problem with this approach is that it becomes somewhat difficult
to make this service function in a dynamic fashion. EG, if I am a mobile
user and I want to list my ISP-dujour as a valid sender for my mail
domain, then I would have to add an MS RR to the domain name, update the
zone, wait for the changes to propagate to the replication slaves and then
hope that the destination sites don't have my earlier MS RRset in their
caches.
For all of these reasons, linking an MS RR to the mail domain name is not
the best design, and it should be avoided. Unfortunately, it is probably
the least worst choice available given the current SMTP model.
An alternative here would be to define a service name for the lookups, and
then using SRV RRs to avoid the owner name overflow problem. EG, come up
with something like _tcp._smtpc.example.com, with the SMTPC service name
providing links to the outbound relay hosts. However, this violates
several different design elements. First of all, the SRV RR defines
servers not clients. Second, there is no fixed port number for clients, so
defining an SMTPC service would be an exception condition. Furthermore,
there are still problems with dynamic updates and caching. In the end,
this approach trades one problem of overflows with other different
problems, and doesn't really get us anywhere.
The other alternative is for the owner domain name associated with the
relay server itself to list domains it relays for. This won't actually do
anything to solve the problem, since spammers can just list yahoo.com as
one of their domains and then we are right back to where we started.
So I think that using an MS RR is the most direct solution to the problem,
although it does introduce additional concerns. However, as was pointed
out earlier, it may also be feasible to allow the existing MX RR to be
reused as supplemental data if no MS RRs are defined. In that particular
scenario, the threat of overflow would be reduced, and for the vast
majority of the cases, this would provide immediate beneifts since most
organizations use the same hosts for inbound and outbound relays (we
wouldn't have to wait for people to add MS RRs to their zones to start
reaping the rewards).
In short:
1) Take the domain element from the reverse-path and do an
MS lookup
2) If no MS RRs were returned, do an MX lookup
3) Locate/extract the A RRs associated with the MS/MX RR data
4) compare the IP addresses of those hosts against the current
connection tuple
5) accept if matched, issue 551 (or something) if not
This will work without any additional effort in the common cases, EG a
direct connection from a sender's submission server with an MX RR, or
indirect through sender-side relay with MS/MX RRs.
This will not work if the messaging clients have their own full-service
MTAs. In that condition, it may be that a special wildcard interpretation
can be defined for use, such as:
example.com MS outbound.example.com ; outbound relay
example.com MS *.eng.example.com ; Engineering dept
example.com MS *.example.net ; ISP network
That would allow all of the hosts in the eng.example.com domain to use
their own MTAs, but without having to list each host. This approach could
also work for roaming users who use different mail servers every day, but
which are always using the same ISP. Note that the above approach won't
work as described but something similar to it can probably be fleshed out
and made usable.
Another problem condition is with delivery servers which are isolated
behind an internal relay server. If the delivery servers generate these
lookups, then the answer set will never match with the IP address in use
(the address of the in-house relay server). Those servers would have to
disable this feature, or would have to add the relay to an internal list
of known-good relays.
The remaining killer problem here is with aliasing, as Philip pointed out.
If mail is sent to user(_at_)example(_dot_)net and is then sent to
user(_at_)example(_dot_)com
-- but the original return-path is retained -- then the sending server
won't match with the MS/MX RRs for the original sender's mail domain. I
think that this can also be handled via whitelist exceptions, as with
internal relays above. If you know that you will frequently receive mail
from a particular alias, then you can add that domain to your exception
list and get all of that mail without any additional work. Plus, if the
incoming servers for the alias domain implement this system, then the mail
will be filtered at that junction, so this won't mandate that you get spam
from those domains.
All of the other conditions should work as normal. Mailing lists that
rewrite the reverse-path will function. Resent-* forwards will work since
the reverse-path will point to the resender. I don't see any other issues
or problem cases.
Thoughts?
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/