On Nov 28, 5:15pm, Hector Santos wrote:
}
} ----- Original Message -----
} From: "Yakov Shafranovich" <research(_at_)solidmatrix(_dot_)com>
}
} > The method you are refering is similar to what is more commonly known as
} > "Challenge/Response" (C/R).
}
} Not the same thing. WCSAP checks the MAIL FROM: state point. C/R
} systems go to the RCPT TO: statement, and in some cases complete the
} session.
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?
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?
On Nov 29, 8:32pm, Bill Cole wrote:
}
} I admit to having only skimmed the stuff on 'CallerID' because it
} looks like the same unscaleable stuff that has been in in some MTA's
} for a while with essentially tries a RCPT verification of every MAIL
} FROM given
In fact -- although I don't have absolute evidence of this -- it appears
that the several days last month when verizon.net was rejecting all mail
from the ASRG list, occurred because verizon implemented a "caller ID"
check of some sort in their mail servers and the IETF mail system was
failing the check. (The list is reaching me again, though I don't know
which end got fixed.)
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.
} and there are probably enough of us managing mail servers
} who will address that sort of behavior as just another attack (null
} route the offending machine) so that the inherent scaling and
} indirect attack problems don't ever make it to visibility.
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?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg