On Wed, 2004-08-18 at 14:28, Alan DeKok wrote:
Dean Anderson <dean(_at_)av8(_dot_)com> wrote:
In the case of SPF, all the virus operator has to do to continue forging
email is to have the virus upgrade itself to use the infected domain's
relays using the user's stored email configuration or just by guessing, or
better, by using the SPF records. After that, they forge away.
One huge benefit to viruses by forging is that millions of user
machines, with fast network connections, who aren't normally MTA's,
can suddenly all attack other peoples MTA's. Like may people, I've
had MTA's severely hit by a new virus load, due to precisely the above
problem.
When transparent interception is not used by network providers, Trojans
are free to submit mail from compromised machines without detection.
Sender-ID may create market disincentives for trapping Trojans in this
manner, although this is an effective ploy where network providers can
handle the outbound problem themselves.
If the viruses have to use the infected domains MTA to propagate, I
think that's a great thing. Their MTA will probably die, won't
distribute as many viruses, and therefore my MTA won't die.
Sender-ID attempts to change the paradigm of being able to use a mailbox
address as an identifier from any point of access. This leaves two
options for ISPs. Create an "open" list, or add a Resent-From header to
the message as a means to accommodate customer expectations. If a few
hundred thousand domains wish to retain this paradigm, then the number
of "open" lists will ensure a Trojan can use a different mailbox for
each spoofed message that "should" be accepted.
If these "open" lists become blacklisted or refused as a result of this
type of exploit, then "open" lists should have never been allowed in the
standard, as it then invites mail failure. On the other hand, if each
message was sent using a hostile domain, both SPF and Sender-ID allow
these lists to encompass a significant portion of the Internet address
space, which enables "throw away" domains to easily stage a broad base
attack.
Viruses can, of course, get around this by using "open" SPF records,
or records from an "evil" domain associated with the virus. But both
of those situations involve a single point of attack: the DNS for the
domain. Shut that down, and there's no longer any SPF records, and
we're back to where we are today with viruses & forgery.
Just as these Trojans exploit thousands of mailbox addresses, these
mailboxes can be culled from a list with "open" records. There would be
no single DNS to enable a shut-down. In addition, these mailbox records
and DNS servers likely represent legitimate users. These users would
react to retaliation tactics, as they have done nothing wrong, and
overload customer support. This assumes mail providers are coerced into
publishing these records initially, without changing the habits of their
users.
So in one situation, we'll be better off. In another, we'll be
worse off, due to the cost of deploying a protocol that doesn't help
for that situation.
If ISPs check their SMTP error logs, those sending spam can be quickly
spotted. For this reason, transparent interception becomes a good
choice incompatible with Sender-ID or SPF, however. ISPs should be able
to track their clients to better enable quick removal, such as
blacklisting at their intercept. Unlike Sender-ID, the channel is self
documenting with CSV, and users become aware of the channel as part of
the identification. If there is a problem, CSV identifies the entity
responsible and safely blocked as a result.
It's up to individual MTA administrators to do the cost/benefit
analysis for the two situations, to see if it's worth it for them to
deploy a particular solution.
Unlike Sender-ID, CSV does not change mail paradigms, but can be an
effective deterrent as illustrated in the MPR draft. Unlike Sender-ID
or SPF, the address space allocated by a particular CSV record is
limited to that normally occupied by a single host, making a broad based
attack more difficult. If there is a case to be made for placing a
restriction on the RFC2822 From, MPR makes this restriction explicit and
can prevent different headers from removing the desired protection. As
providers are not required to create an "open" list to authenticate the
MTA when using CSV and MPR, there is no record available to enable an
exploit.
-Doug