ietf-mxcomp
[Top] [All Lists]

Re: Input on identities

2004-04-06 20:41:46

Hey John,

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.


Greg Connor wrote:

  * Bogus HELO is often used to mislead people.  Checking HELO for
   obvious, outright forgery keeps MY domain from being mentioned
   in a bogus message if I am not related to the sending client.
   This may lead to a reduction in misdirected abuse reports.

--John Gardiner Myers <jgmyers(_at_)proofpoint(_dot_)com> wrote:
Does anyone have evidence of a significant number of abuse reports
misdirected to forged HELO values?


I have received quite a number, directed to abuse(_at_)altavista(_dot_)com, based on nothing other than a faked HELO... but I don't have actual statistics. It's not as much as those due to forged From:

My opinion is that if domain owners want to publish info on HELO, I will honor it... but it's not as important to me as From: / MAIL FROM.


 * HELO is a logical "fallback" in the case of MAIL FROM: <>

The From: header is a much more logical and useful fallback for the empty
return-path.

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. But I can see some reasons you might want to validate From: instead... For legitimate bounces they should be From: MAILER-DAEMON(_at_)something anyway. As I said, if both methods are available, I will probably both.


 * HELO is currently pretty useless because it is not checked, but
   encouraging server admins to use the right name can have long-term
   benefits.

Unless you state what these benefits will be, their value cannot be
determined.

In the Apr 5 conference, the benefit listed was the ability to use a
domain instead of an IP address as an index into some yet to be developed
accreditation/reputation service.  There are, however, numerous RBL
services which demonstrate that IP-indexed reputation services do work.


Misleading text in Received: lines is one thing that I would like to prevent... but this is a low priority compared to From: / MAIL FROM. Yes, this does count as a benefit whose value can't be determined.

I would agree that the value of such benefits can't be determined, but I believe they are valuable nonetheless. I'm willing to do something that I believe improves things in a not-quite-tangible way for some future purpose.

Put another way, HELO is in the RFC821 for some reason, and I'm not quite happy with the state of things today where any old name gets stuck in there and folks just work around it.

Er, unless you were just objecting to my not stating the benefits :) In which case, uh, there is at least one benefit. There are probably more.


Gordon Fecyk wrote:

<>> 2821 HELO/EHLO domain
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.

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?



Hector Santos writes:

However, from what we have learned with a consistent number of hits, the
questions are now:

- Why aren't these people learning?
- Why aren't they adapting to the enforcements?
- Why do they keep trying on what seems to be a daily schedule?


They aren't learing or adapting because your enforcement isn't a
sufficiently large portion of the ecosystem.  My experience at a provider
which was a sufficiently large portion of the ecosystem is that those
people do learn and adapt, quite quickly in many cases.


Actually, that's the best news I have heard all day, with regard to HELO, or any kind of checking. Thanks.


--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>


<Prev in Thread] Current Thread [Next in Thread>