spf-discuss
[Top] [All Lists]

Re[4]: Informal request for comments (a new SMTP-CBV protocol)

2004-06-24 04:17:27
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?

You have to design the protocol to work in a hostile environment where none of these workarounds has been deployed.

>> 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 ?

You said:

: Prevents dictionary attacks, since the RMTA can verify the sender before : letting the attacker know if the recipient exists,

That is the way plain CBV works. You reject all RCPT commands if the sender verify fails.

What does "co-operation from the attacker" mean? "attacker" surely
means you can count on them not co-operating?

You also said:

: and (if the attacker speaks SMTP-CBV) gives the RMTA a "constant" (the : VMTA IP address) to use for throttling attack speed.

This part of your anti-attack mechanism assumes that the attacker is helpfully not lying to you through the CD-CBV protocol. The "constant" that you suggest isn't actually constant in a competent attack, and in any case can be obtained with a plain CBV.

>> 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)...

That doesn't cause loops.


Niggling aside, I'm not convinced that this is a useful extension of plain CBV. The main benefit of it is to advertise conformance with and willingness to participate in the CBV protocol. However this information should not be communicated in-line because it's a property of the domain of the envelope-from, not a property of the SMTP sender (who is probably a lying spammer or virus). A better way of doing this would be via the DNS, e.g. using an SPF extension.


Tony.
--
f.a.n.finch  <dot(_at_)dotat(_dot_)at>  http://dotat.at/
FITZROY: VARIABLE 3 OR 4 BECOMING SOUTHEASTERLY 5 OR 6 IN WEST LATER.
OCCASIONAL RAIN OR SHOWERS. GOOD OCCASIONALLY MODERATE.