Hi Tony,
Again - thanks for commenting
Thursday, June 24, 2004, 9:17:27 PM, you wrote:
TF> On Thu, 24 Jun 2004, Chris Drake wrote:
sender+recipient pair authentication,
TF> Doesn't work in the presence of aliasing (forwarding).
Should be fine providing the intermediate MTAs all speak my SMTP-CBV,
or the intermediate MTA rewrites, or the ultimate destination MTA
cares to get the "To:" addresses from the headers?
TF> You have to design the protocol to work in a hostile environment where
TF> none of these workarounds has been deployed.
I think we fell out of synch someplace - my CBV idea works on MTAs
that don't use my new extension idea already - it just works much
better when they do have my extension in place.
dictionary attack prevention
TF> Doesn't require your proposal. Requires co-operation from the attacker.
It doesn't? how do you allow CBV without message or
sender+recipient-pair identification in a way that overcomes
dictionary attacks ?
TF> You said:
TF> : Prevents dictionary attacks, since the RMTA can verify the sender before
TF> : letting the attacker know if the recipient exists,
TF> That is the way plain CBV works. You reject all RCPT commands if the
TF> sender verify fails.
Yes, which is how dictionary attacks work - feed a valid sender and a
pile of RCPT guesses - my extension overcomes this because the
attacker can't guess a valid email address (and/or message ID) that
the target MTA has used to send a message out from in the 1st place.
In order to get the target MTA to "tell the truth" about what
mailboxes exist or not (or whether or not a given message ID came out
or not), my new CBV protocol requires that the "attacker" provide a
valid email address (or message ID) *** which the target MTA has
already use to originate an email to the attacker ***
What does "co-operation from the attacker" mean? "attacker" surely
means you can count on them not co-operating?
TF> You also said:
TF> : and (if the attacker speaks SMTP-CBV) gives the RMTA a "constant" (the
TF> : VMTA IP address) to use for throttling attack speed.
TF> This part of your anti-attack mechanism assumes that the attacker is
TF> helpfully not lying to you through the CD-CBV protocol.
If they lie, the callback to their "lied" verification server is
obviously going to fail, so they'll get 100% "5xx scram" results for
all VRFY/RCPTs they attempt.
TF> The "constant" that you suggest isn't actually constant in a
TF> competent attack, and in any case can be obtained with a plain
TF> CBV.
Forcing people to use their existing MTA for CBV is a bad idea. It
does not scale, and TCP/IP is very expensive. My idea provides a
mechanism for the specification of an alternate VMTA, which can either
be the OMTA, or some other MTA, or perhaps not even an MTA at all (eg:
a dedicated UDP server).
CBV loop avoidance
TF> Plain CBV does this anyway.
Except for RFC-ignorant and everyone who's disabled dictionary
attacks (ie: accepting anything from <> to a catch-all)...
TF> That doesn't cause loops.
Which is why they don't use the recipient email address as the
"MAIL FROM:" parameter, which robs the verifying MTA of the ability to
know whether or not this is a valid callback, or a dictionary attack.
TF> Niggling aside, I'm not convinced that this is a useful extension
TF> of plain CBV.
I disagree with your reasons for thinking this is not useful,
however, upon much pondering, I'm of the opinion that this really
might not be useful because of the difficulty of getting any reliable
"database" of sender addresses and/or message IDs that will be
available to the VMTA. It's exactly the same problem that SPF
suffers: there's always going to be real people who sent their email
out using some other mail server, so the VMTA isn't going to know they
did this, so it will reject or soft-fail (which then get baysian
dropped) real emails, so I'm back to where I started really, which was
(to paraphrase myself) "All you rabid anti-spammer people are totally
destroying the entire concept of email - sure - spammers made email
hard, but it's the anti-spammers who have made email horrendously
unreliable - all because people are too afraid to "5xx" things, so
they accept stuff instead, and then silently drop it (coz they're too
chicken to bounce/DoS) so nobody knows if anything got through or not
anymore!"
At least I'm back to not-hating SPF so much anymore, so long as we can
convince newcomers to 5xx stuff instead of accepting it and letting
the basian/etc filters silently erase false positives...
TF> The main benefit of it is to advertise conformance with and
TF> willingness to participate in the CBV protocol. However this
TF> information should not be communicated in-line because it's a
TF> property of the domain of the envelope-from,
This is why I specifically asked people to NOT "nit-pick", but to
instead suggest refinements. This is a no-brainer - if the domains
match-up, then it's fine, or the in-line communication might want to
specify this info some other "secure" way, like saying "use my SPF
record" or whatever else. Anything you can dream up that a spammer
can't benefit from is fine.
TF> A better way of doing this would be via the DNS, e.g. using an SPF
TF> extension.
Oops. sorry - I take that back - you did think this up independently
already - FWIW - my idea (in-lining it) might save a UDP packet and
the associated delays and potential uncertainties most of the time
(non-spam), because most MX's will specify themselves or something on
their own domain for handling the CBV, but then - if SPF is already in
use, the relevant CBV data could already have been obtained I guess...
TF> Tony.
Kind Regards,
Chris Drake