Re: [Asrg] 0. General - Inquiry about CallerID Verification

["Hector Santos" <winserver.support@winserver.com>]

>
> 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@winserver.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@whereever.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@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg