Hector Santos wrote:
Suppose a large ISP were to adopt the "caller ID" scheme (one already may
have, see below). A spammer forges winserver.com MAIL FROM: on a couple
of
million messages destined for that ISP, distributed across all its dozens
of MXs. They all begin connecting to your MX to ID the caller. Are you
prepared to handle that load, or have you just been DoS'd into oblivion?
Doesn't this apply to any approach? A DNS based solution can also be
overloaded just as well.
DNS lookups are *much* more lightweight than SMTP sessions. According to
RFC 1035, DNS queries can be done over UDP, with a limit of 512 bytes
per query, with the usual ones much smaller than that. This has two
advantages - very low transfer size, and also the usage of UDP does not
require an acknowledgement to be sent back unlike TCP, reducing traffic.
Also, DNS information tends to be cached all over the Internet.
That is why an DNS method is being pushed in LMAP, since it is more
lightweight. As a matter of fact the "L" in "LMAP" stands for "lightweight".
Plus many domains have their DNS services outsourced to someone else
like UltraDNS, whose systems are more than enough to withstand most DDOS
attacks.
But it doesn't end there. I am going to explore other ideas, such as use
"VRFY" option, which many systems disable but it can be tested, and other
ideas such as maybe using a new EHLO keyword: XSAP
Use of VRFY should be done with caution, many systems may turn it off
and a good reasond to do so, from RFC 2821:
"7.3 VRFY, EXPN, and Security
As discussed in section 3.5, individual sites may want to disable
either or both of VRFY or EXPN for security reasons.
"
From RFC 2505:
"2.11. SMTP VRFY and EXPN
Both SMTP VRFY and EXPN provide means for a potential spammer to test
whether the addresses on his list are valid (VRFY) and even get more
addresses (EXPN). Therefore, the MTA SHOULD control who is is allowed
to issue these commands. This may be "on/off" or it may use access
lists similar to those mentioned previously.
Note that the "VRFY" command is required according to RFC821, [1].
The response can, though, be "252 Argument not checked" to represent
"off" or blocked via an access list. This should be the default.
Default for the "EXPN" command should be "off".
"
ALSO, please do not take my comments as an attack on your approach,
rather I think that what is missing here, is the fact that your approach
is not 100% compliant with the standards. If you are proposing to change
the standards, that's fine but I think that should be made clear.
However, in my opinion as you are proposing it now, this proposal is not
in compliance with existing email standards since it requires the
receiving domains to answer 252 upon RCPT TO to valid addresses only.
That is not a current requirement, and blacklisting Yahoo and others for
doing that is incorrect.
I think that we need to evaluate the current SMTP model first to see how
many holes there are, and THEN see what we can do about them. Since can
help to put things in perspective better.
Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"I ate your Web page. / Forgive me. It was juicy / And tart on my
tongue." (MIT's 404 Message)
-------
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg