Initial thoughts.

[Brian Candler]

On Tue, Feb 24, 2004 at 02:31:00PM +0000, David Woodhouse wrote:
> On Tue, 2004-02-24 at 13:30 +0000, Brian Candler wrote:
> > 2. it's maliciously incorrect (a joe job pointing to someone else), in which
> > case it falls under the different problem case (1), i.e. I don't want to
> > accept bounces to mail I didn't send; or
> 
> Indeed you don't. That's nice for you. Now _I_ am stuck with an
> undeliverable bounce because you quite rightly don't want to accept it.

Then you just discard it. (Exim's default is to freeze double-bounces; first
thing you do on a new exim install is to get it to drop them silently. So
much mail on our smarthosts was bounces to non-existent addresses..)

Yep, I agree that if you could have validated the sender first, it wouldn't
have happened. The only place that can happen usefully is at the ISP's
smarthost though.

If you receive a (deliverable) mail, but refuse to accept it because you
have determined that the return address is invalid, which is an accidental
misconfiguration, then:
- no mail will be delivered, and
- no bounce will be delivered (at best you return 550 to the sending ISP's
  smarthost, which is then left holding the baby and cannot do anything
  with it)

I think think that's a worse situation than just delivering the mail in the
first place.

> > But this is an unstable equilibrium. If SPF does actually deliver some
> > benefit, then everyone will want it, at which point the spammers will bypass
> > it. Personally I think the SRS-signing of outgoing mail as you have
> > implemented gives much greater benefit to the implementor, immediately, at
> > very little cost.
> 
> To the implementor yes, but not to the poor sods out there who don't
> bother to _check_ with me whether that's a valid return-path. 
> 
> That's their choice -- and it's yours. I like to check, though.

Sure. But there are two halves to the equation:
- implement signing of outgoing mails, and bounce validation
- implement callback sender verification on incoming mails

If you implement either one or both of these, you gain immediate benefit. If
the people you are communicating with implement them too, you gain even more
benefit. And you don't have to wait for the rest of the Internet to
implement them before you benefit.

> I wouldn't recommend editing the From: address. I think RFC2821 says you
> MUST NOT. It will suffice to add a warning header that a MUA can look
> for if it wants, or which procmail can use to dump the message into a
> spam box.

OK. End-point policy decision, anyway.

Perhaps in extreme cases, where the sender is known to be very likely to be
forged, the receiving MTA can wrap the entire message inside a
message/rfc822, with a disclaimer on the outside saying that the From:
address is bad.

> > "this mail came through me, and it's one of my domains, the RHS may be right
> > but I can't vouch for the LHS of the address" (this is roughly what SPF
> > attempts)
> > 
> > - a mail from "random at myisp.net", where the user authenticated with SMTP
> > AUTH and with a username which matched that address, could be signed "this
> > mail came through me and I vouch for the authenticity of the sender"
> 
> I _can_ see the point in making a distinction between the above two
> cases, but I wonder if it's really _necessary_. Any proposal has to be
> lightweight and we must avoid featuritis.

The first is easy to implement now, but doesn't actually validate the sender
(much). The second is a much more desirable position of having a
fully-validated sender, which ought to be a long-term goal.

> > - a mail from "b.candler at pobox.com", where I authenticated with SMTP AUTH as
> > brian at myisp.net" could be signed "this mail came through me from the user
> > brian at myisp.net, but I cannot vouch for the sender address given"
> 
> According to RFC2822, in this case you should have brian at myisp.net in
> the Sender: header, and b.candler at pobox.com in the From: header. 

Sure. Sender: headers can be forged too, of course. Effectively this would
be a crypto equivalent of the Sender: header though.

> > Such policies could allow existing practices to continue working, and for an
> > address which cannot be fully vouched for (which would be the vast majority
> > in the early days), you at least get _some_ information about the sender or
> > the domain.
> 
> I think we could address this differently. The pubkey-in-DNS scheme
> should allow you to specify different pubkeys on a per-user basis if you
> want to. That way, the user himself can add the signatures using his
> _own_ private key, and the ISP-de-jour doesn't have to be involved.
> 
> That'll be by _far_ the most common case, surely?

The ISP would have to be involved by publishing the end-user's public key in
the DNS somehow, e.g. under  "b.candler._at.pobox.com."

(or else by signing the end-user's key, as mentioned before)

The ISP probably does not want to be responsible for holding the user's
*private* key, in which case the end-user's MUA must be responsible for
signing the message. Here we move away from an ISP-centric solution to an
end-user-centric solution, which has defied widespread acceptance to date.

> > Hmm. Let me put it another way. Suppose in our smarthost MTA we see a mail
> > which says
> >    From: president at whitehouse.gov
> > 
> > but whitehouse.gov has not published any key information, so we know the
> > recipient won't be able to verify it one way or the other.
> > 
> > I think it would be better for us to sign it saying "This mail probably came
> > from *@myisp.net", than not sign it at all. The receiver then has something
> > to verify (using the myisp.net key in the DNS) and show to the end-user.
> 
> But it means nothing. It's like signing a memo you found on your desk
> without reading it, just to say "I saw this and it really did exist".
> 
> I disagree that such a signature would be useful.

I will think about it some more, but it seems useful to me, particularly in
the early stages where otherwise early adopters gain nothing.

> > Since the certification disagrees with the originally-provided From: header,
> > the end-user has a better indication of a forgery than if no signature were
> > applied, even though whitehouse.gov has not published anything.
> 
> Why a better indication of a forgery? No information is available as to
> whether this could be valid or not. Do you think it _is_ or it _isn't_
> if you find such a signature? I don't see how any information is gained.

If whitehouse.gov does not participate in this scheme, then mails you
receive which say 'From: president at whitehouse.gov' may:

(1) be genuine, coming through the whitehouse.gov systems
(2) be invalid, coming through some other system which supports crypto
signing
(3) be invalid, coming through some other system which does not yet support
our nice crypto signing scheme

If we sign such mails, we can identify case (2), even if otherwise we cannot
distinguish between cases (1) and (3). Some forgeries may be detected. If
our system became popular, case (3) would be squeezed out.

It's essentially an ISP making a negative assertion: I do *not* handle mail
for whitehouse.gov.

> > > If we _do_ have a per-user key scheme where the end-user has signed a
> > > message using their own key, why would it need signing by the ISP too?
> > 
> > We need to add some level of the ISP 'vouching for' the user - which, unless
> > the end-user's key has been signed by the ISP, means signing the message
> > somehow.
> 
> The ISP vouches for the user by listing the appropriate pubkey in the
> DNS for that user at isp-domain. Isn't that sufficient?

Yes it would be. This wasn't discussed until now.

The problem is that either we support keys and signing for all the various
existing mechanisms, or we just implement a new mechanism which can sit on
top of all of them anyway. If we do that, we don't care that it's already
been GPG-signed, say.

> > > Verifying the signatures in the MUA can still do the DNS lookups to get
> > > the pubkey, though, surely? Just like SpamAssassin can do RBL and SPF
> > > lookups. You're normally online at the time you _fetch_ the mail, or you
> > > wouldn't be able to talk to the mail server.
> > 
> > Not if you're offline (i.e. disconnected from the Internet)
> 
> Then you're unlikely to be fetching your mail, surely? I think we can
> declare this an uninteresting sub-problem.
> 
> 	"How do you look up keys in the public database while offline"
> 	"You don't."

So I guess you mean, remove the goal that signatures can be checked offline.

Cheers,

Brian.