RE: CBV

> From: Stuart D. Gathman
> Sent: Sunday, May 16, 2004 8:10 PM
>
>
> On Sun, 16 May 2004, Tony Finch wrote:
>
> > > To validate a message, a recipient does CBV with either
> > > a MAIL FROM of <> or a MAIL FROM selected from the message envelope
> > > recipients.

You really can't do a CBV with anything but MAIL FROM:<>.  We could come up
with something that flags that this is a special query, but that changes
SMTP and would be a very tough row to hoe.

I proposed a slight variation to this that is compatible with current SMTP
in my previous post listing various ways to do SES.  The recipient does a
normal null-sender CBV.  If the CBV returns a 250, the recipient then issues
the EXPN command with the extended precision timestamp-indexed local address
for an argument.  The SMTP-server expands this list into the list of
original RCPT TO: addresses.  This mechanism is part of RFC2821, but
requires that the originating gateway MTA store the list expansion for the
timestamped local address for each outgoing message.

This accomplishes your original goal of connecting a given MAIL FROM:
exclusively with a given list of RCPT TO:'s and it does so without breaking
SMTP.  Though many MTA's have shut off the EXPAND function today, they would
only need to enable it under this one very limited circumstance: the MX has
just answered a CBV with a 250, proving that the SMTP-client was in
possession of a MAIL FROM: that came from that MX, and the SMTP-client then
asks to expand _that exact_ return address to get the list of RCPT TO:
addresses.  Any other attempted use EXPN could still be denied.  Therefore,
this does not provide a security exploit.

I personally think this variation is the best of the bunch of the SES
proposals when replay attacks are possible, but let's see what others think.

>
> > It is often the case that none of the original recipients are available.
>
> If you are not one of the recipients, then you certainly don't want
> the mail - unless you have arranged for it to be forwarded by
> some outfit that doesn't do SRS, in which case you would have
> the appropriate whitelist.

Agreed, the recipients who use this have to whitelist their own forwarders.
I don't see this as a significant limitation.

>
> SES/SESR doesn't break sender forwarding (e.g. the hospital
> sending baby pictures with your email as MAIL FROM).  Although
> spam filters
> will likely look askance at an unauthenticated sender.  With cryptographic
> validation, you could put the hash secret on your Palm Pilot (or Zaurus
> or whatever) and have it give you a valid SES/SESR sender address
> for use with sender forwarders.

That is one of the nicer properties of any SES scheme: if you hand an MSA a
SES-signed return-path, that MSA can do a CBV to the appropriate MX and
validate your right to use that return path before accepting the message.
This authentication is down to the user level, not just the domain.  With
this mechanism, people can again send mail from anywhere, as long as they
can authenticate who they are by providing a valid SES signature that will
pass a CBV to their domain MX.

>
> > > Existing practice is to use <> as the MAIL FROM for CBV (is this
> > > true?)
> >
> > Postfix does callouts using postmaster@.... in the reverse path.
>
> Then this would need to be a special case: treat postmaster@...
> identically
> to <>.

This is only done to support the fact that a few MTA's do CBV's with this
mechanism in violation of RFC2821.  It is not a good practice and hopefully
those who do it will eventually stop.


>
> > > If we send something other than <> in the MAIL FROM for a CBV
> > > to an MTA
> > > that has never heard of this idea, will the CBV still work as
> > > intended?
>
> > Not necessarily. The MTA may reject non-bounces to sender-only
> > addresses.
>
> Then we would need to flag SESR and send only plain <> for plain SES.

Or use another mechanism that does not break RFC2821.  We could flag SES
signed addresses that will expand the recipient list by using, for example,
SES1 as the initial string.  I would argue against this, however, as it
would give attackers a signal as to which SES addresses could be hijacked.
I think it is better to have all the SES signed addresses look the same, and
if an MX does not care to support RCPT TO: address list expansion, it can
simply decline the EXPN command.

--

Seth Goodman