Re: Input on identities

John Gardiner Myers wrote:
> Doug Royer wrote:
>
> > [HELO checking] keeps admins from spending time trying to figure out 
> > which domain really sent the email by having to go to ARIN (or
> > whichever) when everything in the spam is forged.
> So verifying the HELO domain gives the verifier a key it can use to 
> better make abuse reports. Is this a fair summary of the claim?
> What would inhibit spammers from simply using unverifiable domains in 
> HELO?  What is the incentive to get legitimate unverifiable senders to 
> publish  HELO authorization records, that they will otherwise get a 
> large number of misdirected abuse reports?
Verifying HELO provides the following benefits, in no particular order:
1. Prevents forged domains from appearing in Received headers, which
  a) reduces misdirected abuse reports sent to forged domains
  b) reduces incorrect reports sent to 3rd-party reputation services
2. Links a peer MTA to an accountable domain
3. Provides a base for further validation proposals to work with. For 
example, SPF currently provides mechanisms to include various meta-entities 
in the list of systems allowed to send using a specific domain in MAIL FROM. 
MTAs authorized to use, for example, a hosting provider's domain in HELO 
could be included in a hosted domain's records by reference to the hosting 
provider.
4. Can use this domain as a reference to a reputation/accredidation service.
5. Nothing breaks as a result of checking HELO, because it has no inherent 
association with MAIL FROM or any RFC 2822 headers.
> > > The From: header is a much more logical and useful fallback for the 
> > > empty return-path. 
> > It's logical when it can be trusted. Almost all of the time when the 
> > HELO value is bogus, so is the MAIL FROM and From: value.
> If we checked the authorization records, we could trust it.  The 
> proposal I was responding to was one where the receiver checks the 
> domain of MAIL FROM if it is non-empty, but checks HELO when MAIL FROM 
> is empty.  My point is that an algorithm that instead checks the domain 
> in From: when MAIL FROM is empty would be much more logical and useful.
Look at it this way: a peer MTA is either authorized by the domain it claims 
in HELO to relay bounce messages, or it is not. In most properly-configured 
MTAs, 2822 From will contain the domain that originated the bounce. However, 
that may not necessarily be the peer MTA.
Consider the case of a domain's MX that accepts a message it must later 
bounce, but which must relay through a smarthost. The smarthost is 
authorized by the service provider that runs it, and would have propoer 
records. If you want to check 2822 From as well, the MX domain's records can 
then reference the provider's records.
> Greg Connor wrote:
>
> > You seem to have a bias against HELO checking.  Perhaps it would be 
> > more effective to state "I don't like the idea of HELO checking" and 
> > say why you feel that way, rather than taking apart other people's 
> > statements when they disagree with you.  It's OK to disagree, but I 
> > find it's clearer if you do so in a straight-forward manner.
> I am skeptical that HELO checking is worth the cost.
What do you believe to be the cost?

> Many people advocating HELO checking are being unclear as to why they 
> believe it would help.  The arguments parse as "With HELO checking, the 
> receiver has a verified domain identity of the sending MTA.  Then a 
> miracle occurs.  We then have reduced spamming."  I'd like to get more 
> clarity on that middle step.
Have a look at the top of my message. We provide accountability, prevent 
nasty side-effects of forgery, and eliminate a class of unwanted messages 
resulting from erroneous assumptions of misuse/abuse.
> Clearly stated arguments include "publishers of authorization data get 
> fewer misdirected abuse reports due to bad data in Received:" and "the 
> verified HELO identity can be used as a key into a yet-to-be-designed 
> reputation service."  There appear to be other claims that have not been 
> adequately and clearly expressed.
> It would be useful for any resulting spec to clearly articulate the 
> expected benefits of implementing the protocol.
> > That is debateable.  My "best" preferred case would be to be able to 
> > check all three, HELO, From:, and MAIL FROM.  However, if I were to 
> > choose one, in case of MAIL FROM: <>, I would probably choose HELO as 
> > a fallback, mostly because, dropping the connection before DATA saves 
> > me threads and bandwidth.
> An attacker that forges From: but not HELO will be able to do more 
> damage than one that forges HELO but not From:.  HELO checking is not 
> made more valuable in the case of an empty MAIL FROM--it is either worth 
> checking all the time or never.  From: checking is made more valuable in 
> the case of empty MAIL FROM because in that case the checker knows list 
> expansion has not occured and thus will not be broken by checking.
I would advocate checking HELO all the time. At a more advanced stage, I 
would advocate checking all three, as you suggest. Many people here seem to 
have adopted the view that HELO checking is the lowest-hanging fruit, and I 
agree with them.
> > Gordon Fecyk wrote:
> >
> > > > Useful for verifying the identity of a MTA only, but this is very 
> > > > useful to know for such things as delivery status notifications,
> > > > allowing store-and-forward when the MTA isn't a sender for a
> > > > domain, and similar.
> > > <> 2821 HELO/EHLO domain
> > >
> > > How is it useful to know?  What does verifying the identity permit the
> > > receiver to do?
> > Looks like Gordon answered that... allowing store-and-forward when the 
> > MTA isn't a sender for a domain was one example.
> > I am not sure if you are asking to get info, or challenging because 
> > you disagree.  Can you clarify?
> It is not clear to me what he means by "allowing store-and-forward" or 
> how it is that HELO checking allows store-and-forward.  What specific 
> steps can the receiver take, having verified the identity, to do what 
> particular useful thing?
The recipient MTA can test whether the domain a peer MTA claims to be part 
of has claimed accountability for that MTA's actions. In the (very 
hypothetical) case of a message in which all possible domain-referencing 
headers appear, and none match each other, would you prefer to accept a 
message for which none of those domains has explicitly accepted 
responsibility, or one for which one or more accepts responsibility?
> Hector Santos wrote:
>
> > We see about 15%-20% on spoofed HELO domain literals or syntax errors,
> > i.,e HELO [our address] and about 12% rejections based on local domain
> > spoofs, i.e., helo santronics.com, helo winserver.com, etc.
> Could you clarify what those statistics mean?  Is it that 15%-20% of the 
> abuse reports you received were misdirected to you because of a spoofed 
> HELO?  How would you get an abuse report misdirected to you due to a 
> syntax error?
He means (from prior conversations with him) that 12% of MTAs his domains' 
MXs receive connections offer HELO arguments of his domain. As in, they 
connect to the MX for winserver.com and offer HELO winserver.com.
> > Excellent point John.  The spammers still see a majority of unprotected
> > systems. No need to adapt yet.
> >
> > When they do adapt, then many will begin to die or go straight.
> Usually they adapt by using a slightly different attack.  The necessary 
> thing is to have the measure and adaptation result in net progress.  For 
> example, requiring senders to use a registered domain is not helpful, as 
> the resulting adaptation, forging an existing domain, leaves us no 
> better off than we were before.  Requring senders to use a domain over 
Forcing the use of a registered domain is helpful, because it then means 
that we can perform further validation in connection with that domain.
> which they have control is helpful, on the other hand, as we end up with 
> a value we can use in a reputation system, we reduce collateral damage 
> done to domains which would have otherwise been forged, etc.
Spammers can only have control over domains that are registered (to them). 
In checking for that control, we are implicitly checking registration as well.
> Dave Crocker wrote:
>
> > JGM> Unless you state what these benefits will be, their value cannot be
> > JGM> determined.
> >
> > They've been stated.
> They certainly weren't clearly expressed in the message to which I was 
> replying.
> >  For example:
> >
> >     If the client of an exchange can be authenticated, then
> >     it is possible to develop an accountability mechanism
> >     for it.
> So in other words, you want to use the verified HELO value as a key into 
> a yet-to-be-specified accountability mechanism.  Is that a fair summary 
> of the claim?  I believe my questions above to Doug Royer also apply here.
That is a fair summary of one claim. See the beginning of this message for 
others.
Philip Miller