Initial thoughts.

[Seth Goodman]

> {Brian Candler]
> I had another thought. Given the information "this mail has
> been through
> myisp.net's mailserver", a hybrid SPF-like system might
> become feasible,
> because you've eliminated the forwarding problem.
>
> i.e. (1) outgoing mail is signed "I've been through myisp.net"
>      (2) domain foo.com declares in SPF "mail can originate
> from myisp.net"
>          (rather than "mail can originate from IP addresses X,Y,Z")
>
> Doesn't really gain you much, except that the outgoing mail
> relay needs no
> intelligence (it doesn't need a database of which domains to
> sign). That
> information goes back into the DNS. It does hand some control
> back to the
> domain owner though; if I own a domain, and decide I am going
> to send mail
> via isp1.net at work and isp2.net at home, I can declare in
> the DNS that
> fact.
>
> As for the problem of mails being modified and resent: the alternative
> solution is to make the signatures time-expire, like SRS, and
> check them at
> receipt time only. Much less strong because they could be captured and
> re-used for a short period of course, but at least not
> subject to the SPF
> forwarding problem. But then, SRS and callbacks achieve the
> same without any
> public key infrastructure at all.

I tend to like this proposal for a couple of reasons, but I want to
express a couple of thoughts before I say why.

Here is my own personal list of possible goals for something better than
the current SPF+SRS, some of which were already listed by others.  Some
of these are easier than others, some are already done by other means
and some we can live without.

1) Permit a gateway SMTP-recipient to detect and reject as many sender
forgeries as possible before DATA (authenticate original sender at the
receiving end).

2) Facilitate a gateway SMTP-sender to detect and reject as many sender
forgeries as possible.

3) Permit a gateway SMTP-recipient to detect and reject as many DSN
forgeries as possible before DATA (reject joe-jobs at the receiving
end).

4) Permit a gateway SMTP-recipient (or perhaps the user MUA?) to detect
and reject certain header forgeries after DATA (authenticate DATE:,
FROM:, TO:, etc. headers at the receiving end).  Though spammers'
SMTP-senders often hang up after dumping their DATA and don't wait for
rejects, this is the best we can do under the current SMTP framework.

5) Permit a gateway SMTP-recipient (or perhaps the user MUA?) to detect
and optionally reject certain body tampering after DATA (authenticate
message integrity).

6) Use DNS rather than public-key infrastructure.

7) Have significant benefits even in the absence of widespread adoption.

8) Interoperates with legacy systems.

9) Don't create open relays.

10) Don't create replay exploits, if possible.


I put a high value on being able to reject mail before DATA, or at least
immediately after the DATA command but before receiving the data, as
some have argued for.  This saves large amounts of bandwidth and may
possibly get you off some spam lists.  With current SMTP, about the only
things we can add to the existing RFC reasons for rejecting non-DSN mail
early in the transaction is a bogus return-path or an SMTP-sender that
we think shouldn't be sending mail for a given domain.  Everything else
comes after data.

I like Brian's combination of single-level SRS with SPF to make
per-domain configuration at ISP's automatic.  This completely avoids
sender rewriting and we only do checks at the originating and target
MTA's.  Here's another straw-man proposal along the lines of David's
combining Brian's ideas with some of my own.

----------------------------------------------------

1) At the originating gateway MTA, validate the user.  If the MTA is
within the organization that owns the domain(s) that appears in the
From: and Reply-To: fields, and the user passes local policy tests,
accept the message.  Otherwise, look up the SPF record for the domain in
question, verify that the user is allowed to use the domain name from
this MTA and if so, accept the message.

2) At the originating gateway MTA, create a return path with two private
key signatures:

MAIL FROM:<sender_sig1+sender_sig2+TT+local_part+domain at originating_MTA>

where

   sender_sig1 protects the remainder of the address

   sender_sig2 protects the SA (Sender_Auth) header, the
      headers listed in the SA header and the number of
      bytes of the message body specified in the SA
      header; this signature is optional but is
      recommended to prevent replay attacks


3) At the originating gateway MTA, create an optional SA header
containing information as to which header lines protect and the size, in
bytes, of the message body to protect.  This header is as follows:

X-Sender-Auth:<headername1+headername2+...+headernameN+body_bytes>

where

   headernameK is the name of the K-th header field
      to protect

   body_bytes is the number of bytes in the message body


4) At the final gateway MTA, perform any desired tests on the
SMTP-sender:  rDNS, forward lookup, IP blacklist, etc.  If it fails any
test, terminate the session.


5) Upon receiving the MAIL FROM: line, do a DNS lookup to get the public
key for domain.  Verify sender_sig1 with this public key.  If it fails,
terminate the session.  Upon receiving RCPT TO:, check for valid
addresses, if possible.  If invalid, terminate the session.  Otherwise,
accept the address and enter the DATA phase.


5) Upon receiving the message data, verify sender_sig2 using the public
key for the domain.  If it passes, accept the message for delivery,
otherwise, reject it, if the SMTP-sender is still there.  If the
SMTP-sender has hung up, send a DSN back to the SMTP-sender.


Notes:

a) The DNS for a domain must contain an SPF record and a public key.

b) No callbacks are required in this implementation, but an alternate
implementation using them is possible.  Specifically, the verification
of sender_sig1 in step 5 could be replaced by a sender callback.  In
that case, the sender_sig1 field would be replaced by a hash.

--

Seth Goodman