HELO verification

[David Woodhouse]

On Tue, 2004-02-24 at 15:48 +0000, Brian Candler wrote:
> I categorise this discussion under the heading "what do people think they
> will gain from SPF?". If we understand what people think they will gain from
> SPF, we can perhaps offer them a better solution.

OK.... I haven't been aware of much discussion about SPF verifying
_HELO_ addresses, although I was aware of the possibility of using it
when the sender is empty. Actually SPF as a way of limiting _HELO_,
rather than MAIL FROM:<> is a relatively _sane_ plan. Except of course
it'd be called HPF :)

> But: these are *obvious* forgeries. Anyone who knew what they were talking
> about would look at Received: headers only, and only the parts which can be
> trusted (i.e. ignoring HELO names provided by remote hosts).
> 
> So the only benefit which SPF gives is to give better quality information in
> these headers, so you don't have to sort the wheat from the chaff manually.
> 
> IF that's what they want, THEN structuring and/or crypto-signing that
> information is a better solution than attempting to validate MAIL FROM and
> HELO names based on the IP address of the person connecting to you, a la
> SPF.

I really think you'll never manage to make it obvious enough that it
actually improves the behaviour of random dimwits out there. Show a
concrete proposal which disproves my scepticism and I may change my
mind.

> Well, at least you said "this memo has been on my desk". Someone *could*
> attach some importance to that fact, depending on whose desk it is, and how
> hard it is to get something onto it.

OK, OK. It's just another 'trust level' I suppose.

> Let's face it, if you are just checking the RHS of a domain (like SPF or the
> system we're discussing, without SMTP AUTH), you are saying no more than
> this:
> 1. this mail has been through myisp.net's mailserver
> 2. its RHS domain happens to be one of the domains which myisp.net handles
> 
> A large ISP can easily have 10,000 domains handled for its customers. In
> that case, "this mail has been through myisp.net's mailserver" is actually
> the main piece of information.

Assuming that ISP does nothing to prevent the users from forging each
others' addresses, yes.

> 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.

You're speaking of something akin to the SPF 'include' mechanism. Yes,
we want a fairly flexible way of specifying, for any given
domain/address, what keys should be considered acceptable. 

I don't really consider that to be an interesting problem. Feel free to
fill in the blanks :)

> 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. 

You can limit the amount of modification you permit -- as a local
policy. You can also limit the amount of time after the date in the
signed Date: header which you'll allow. 

I think that has to be enough -- I don't think we can do better.


-- 
dwmw2