[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.