spf-discuss
[Top] [All Lists]

Re: A couple of thoughts

2004-02-16 08:50:09
----- Original Message -----
From: "Brian Candler" <B(_dot_)Candler(_at_)pobox(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, February 16, 2004 12:07 PM
Subject: Re: [spf-discuss] A couple of thoughts

On Sun, Feb 15, 2004 at 05:42:34PM +0000, Mark wrote:

  bounce:

    MAIL FROM:<>
    RCPT 
TO:<srs0+hash+ts+example(_dot_)com+b(_dot_)candler(_at_)example(_dot_)net>
    250 valid bounce

    MAIL FROM:<>
    RCPT TO:<b(_dot_)candler(_at_)example(_dot_)com>
    550 Bounce message is not cryptographically signed

From now on, we know that all mail received *from* 
anyone(_at_)example(_dot_)com
will be signed. So at receiving mail systems, a simple 'callback' SMTP
probe can be used to validate the address, the same as many spam
filters use already. If the callback looks like a bounce, it will be
rejected if unsigned.

A 'callback' SMTP probe is already widely deployed by, for instance,
"milter-sender", which uses real-time sender address verification for
regular addresses. To quote their manual: "To be in good standing, the
MX server of the sender must be reachable and willing to accept email
for the sender from the Delivery Status Notification (DSN) address,
which is the null address <> used for error reporting." (not just a
matter of being "in good standing", actually, but simply a requirement).
The procedure is simple: they issue an "RCPT TO: <address>" to see
whether the recipient is valid. The "omr-m*.mx.aol.com" mailers at AOL,
for one, use this too. This:

    MAIL FROM:<>
    RCPT TO:<b(_dot_)candler(_at_)example(_dot_)com>
    550 Bounce message is not cryptographically signed

Can therefore not be used in its blanket form (at least not without
breaking the world).

Errm, I'm lost there. I don't know what 'milter-sender' is, but you said
it verifies the *sender* address of a message, right?

If I have configured my system to reject non-signed bounces as quoted
above, this is because *all* my outgoing mail is signed. Hence if
milter-sender sees an _unsigned_ mail purporting to be from me, it
must be forged, because I didn't send it. And therefore it's right to
be rejected.

The SMTP 'callback' I was talking about, is used in mailing lists, for one;
the spamassassin list, at lists.sourceforge.net, uses this. When you send a
message to the list, their MTA makes a "sender verify callback" (as they
call it) to your subscription address (not the SRS signed envelope-from!),
to see whether the subscription address is still valid. Like so (real-live
example):

--- 220 asarian-host.net ESMTP + SPF Sendmail 8.12.11/8.12.11; Mon, 16 Feb
2004 16:08:53 +0100 (CET)
<-- HELO sc8-sf-mx2.sourceforge.net
--- 250 asarian-host.net Hello lists.sourceforge.net [66.35.250.206],
pleased to meet you
<-- MAIL FROM:<>
--- 250 2.1.0 <>... Sender ok
<-- RCPT TO:<admin(_at_)asarian-host(_dot_)net>
--- 250 2.1.5 <admin(_at_)asarian-host(_dot_)net>... Recipient ok
<-- RSET
--- 250 2.0.0 Reset state
<-- QUIT

This is NOT an unsigned bounce which must be rejected, but simply a legit
SMTP probe! A certified bounce, in contradistinction to a probe of this
kind, would have for recipient not my regular email address, but the SRS
signed envelope-from.

I would perform the following at RCPT TO time:

  IF the envelope sender is <>, then
    (1) if this is the second or subsequent RCPT TO,
        reject 550 unconditionally
    (2) if the recipient does not carry a valid SRS signature, reject 550
    (3) otherwise accept the bounce [and strip off SRS as approproiate]

This solution does not require a tricky scrutiny of the message DATA,
and is solely based on the "logic" of how regular SMTP probes operate.
To recapitulate:

1): empty envelope-from + DATA phase = message for which we require a
cryptographically signed SRS recipient;

2): empty envelope-from - DATA phase = regular SMTP probe; no
cryptographically signed SRS recipient required.

Ah. Are you saying that people might want to verify a *recipient* address
using an SMTP probe, before actually sending a message?

Yes. That is the purpose of what 'milter-sender' does, and other such
implementations.

   MAIL FROM:<>
   RCPT TO:<B(_dot_)Candler(_at_)pobox(_dot_)com>       # check this address 
is valid
   250 OK
   QUIT

versus:

   MAIL FROM:<>
   RCPT TO:<B(_dot_)Candler(_at_)pobox(_dot_)com>
   250 OK
   DATA
   ... this is a bounce
   .
   550 This bounce is not signed

Exactly. :) That is precisely what I proposed in my Nr. "1)" check: if the
have an empty envelope-from AND we have a DATA phase, then we REJECT the
message, saying we need a cryptographically signed SRS recipient.

That is also why I said this method does not require a cumbersome scrutiny
of the DATA to determine whether it is a legitimate bounce: because the very
tripartite condition of having,

a): An empty envelope-from,
b): AND a DATA phase,
c): AND a cryptographically unsigned recipient,

Is itself enough to REJECT the message as a forged bounce.

That's easy enough to implement (in exim, anyway :-) Just defer the
signature test until the end of the DATA phase.

That is what I suggested. :) In case of an empty envelope-from, we delay the
test until the DATA phase; at which point we can REJECT immediately if we
have a cryptographically unsigned recipient.

Regards,

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx