It does share an important "feature" of C/R systems, though: It's cost-
shifting. If someone (or some worm) sends you 1000 messages with forged
senders in the brasslantern.com domain, you're going to hit my MX host
1000 times to refute them all. Why is it *my* responsibility to expend
bandwidth and server cycles to help you reject the spam run? How is what
you're doing to my server any less an abuse of resources than what the
spammer is doing to you?
Correct. Optimization is surely next on the list for WCSAP.
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.
But no, your right. The process has to take this into account. My main
design goal was to work out the interface into our SMTP state machine - a
black box concept.
Abuse, blacklisting, optimization is next for this specific implementation.
I already have some ideas that address this. A cached or database is
required, maybe timed based. This could also be based on a network of
peer-to-peer systems.
More recently, I missed a message from another mailing list, and got a
bounce probe from the list software (which fortunately came through)
because my MX forwarder's DNS went down briefly, causing verizon's test
to fail. This seems excessively brittle to me.
If I felt it was, trust me, I wouldn't be putting it in our system. It
works. The kinks need to be worked out. By far, it is the #1 method to
drastic reduce spoofing spammers using current technology - TODAY!
Exactly -- a "MAIL FROM: <>" followed by "RCPT TO:" an unknown address
is the signature of, for example, a system that is bouncing wormspew to
the worm-forged sender address. How would the administrator of the MXs
that are being "caller ID" probed, know the difference?
Good point.
What we did here was to make the HELO and MAIL FROM: definable. So you can
define what you want to put in there:
SapMailFrom <wcsap-callerid(_at_)winserver(_dot_)com>
SapLocalHost <winserver.com>
One of the beta testers needed to do this for his HOTMAIL account which is
violating the RFC by not accepting NULL addresses.
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
C: EHLO winserver.com
S: 250-winserver.com, Pleased to meet you.
S: 250-XSAP
S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
S: 250-AUTH=LOGIN
S: 250 HELP
C: XVALIDATE xy(_at_)whereever(_dot_)com
That way we can use MAIL FROM and also a loops.
--
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg