Re: Input on identities

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?
> > The From: header is a much more logical and useful fallback for the 
> > empty return-path. 
> Its 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.
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.

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

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