spf-discuss
[Top] [All Lists]

Re: A couple of thoughts

2004-02-16 04:06:58
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.

As wayne pointed out, the message will need to be examined,
carefully, to ensure that we are indeed dealing with a real bounce message,
and not just another, also legit, SMTP probe.

A probe does not have a DATA phase, so there's no message to be examined.

A genuine bounce can be accepted immediately, because it's to a signed
address, and therefore must be in response to a message we sent.

The practical solution could be simple. Since a regular SMTP 'callback'
probe, such as "milter-sender" does NOT enter the DATA phase (and why would
it?), your unsigned bounce-message probe could be delayed until the DATA
phase. Then the rule is simple: "If we had an empty envelope-from, <>, then
we bounce when the single (!) recipient is not cryptographically signed."

I don't understand the difference here, unless you're also checking that a
mail from <> does not have multiple recipients, which is actually a weak
check compared to the cryptographic one so I don't think benefits much.

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]

  IF the envelope sender is not null (which can be done at MAIL FROM time,
  or at the time of the first RCPT TO)
    (1) Perform an SMTP callback with
            connect to MX host for the domain
            MAIL FROM:<>
            RCPT TO:<user(_at_)domain>
    (2) If the response is 2xx, continue. If 4xx or 5xx, reject the
        received message with 4xx or 5xx accordingly.

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? i.e.

   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

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

However this breaks my suggestion that the SMTP callback by itself could
prevent sender forgery.

Regards,

Brian.


<Prev in Thread] Current Thread [Next in Thread>