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

Hi Tony,

 

Thanks for the feedback.

 

Wednesday, June 23, 2004, 9:03:29 PM, Tony wrote:

 

TF> On Wed, 23 Jun 2004, Chris Drake wrote:

>>

>> TF> So if the recipient does a CBV anyway, what's the advantage over

>> TF> properly specifying plain CBV?

>>

>> per-message authentication

 

TF> You can do that with a standard for signed return paths and plain CBV.

 

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

 

>> 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 ? Remember that zombies usually do these now (from

my experience over the last 3 months, they do so almost exclusively).

 

What does "co-operation from the attacker" mean? "attacker" surely

means you can count on them not co-operating?

 

>> OMTA CBV "opt out" mechanism,

 

TF> Especially useful for attackers.

 

Only if they don't mind their domain and VMTA's IP getting instantly

blacklisted? We *could* "encourage" people not to "opt out" by

allowing a header stating such results to be introduced (and hence

picked up baysian-style and used to trash the recalcitrant ISPs

customer emails)

 

>> improved reliability with existing (non-CBV-aware) MTAs

 

TF> Properly specifying plain CBV will acheive this.

 

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

 

>> alternative verification service features,

 

TF> Possibly useful.

 

>> TF> The protocol you described performs the CBV between DATA and its response,

>> TF> which is after the oMTA has found out about the recipients.

>>

>> The OMTA only knows if the recipients are valid after sending the data

>> and waiting for the response from the RMTA (which, in my scenario,

>> does the CBV inbetween).

 

TF> In order for CBV to work you have to be truthful in your response to RCPT.

TF> Any CBV specification must cope with systems that are not.

 

That's the dual-purpose of the "bogus" VRFY-styled SMTP-CBV recipient;

to determine both the SMTP-CBV MTA support, and (if not supported)

whether the MTA is truthful or not.

 

TF> Are you proposing that messages should be rejected in their entirety

TF> because of one mistyped recipient address? What about mailing lists?

TF> e.g. one subscriber's account at a site is cancelled and all the other

TF> subscribers at the site lose their subscriptions.

 

The OMTA doesn't care if some recipients don't exist, and each RMTA

doesn't care about other recipients for their specific message, and

non-existent recipients wont be accepted at all anyhow, so this makes

no difference. It's the *sender* getting verified, not the

recipients. If the sender somehow got their account cancelled before

all their emails got delivered, then all outstanding ones will get

rejected (bounced locally to postmaster of the OMTA if they didn't

trash their queue when they deleted the account).

 

Kind Regards,

Chris Drake

 

---

Sender Policy Framework: http://spf.pobox.com/ Archives at http://archives.listbox.com/spf-discuss/current/ Send us money! http://spf.pobox.com/donations.html To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com