GC> 4. Some checking of RFC 2821 HELO might be helpful but this should
not be GC> the main focus of the sender authentication effort.
--Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
Why?
What is it that we can be certain of learning from Mail From, versus
what is it we can be certain of learning from EHLO?
And why is one more important than the other, for control of spam.
Actually, I don't have a strong preference regarding HELO checking, so let
me back off of my previous statement a bit. I would like to see the first
push aimed at RFC2821 MAIL FROM, but beyond that, HELO checking might have
some value too. Clearly both HELO and MAIL FROM were important enough at
one time to make it into RFC821.
I have a general idea that there is a lot of broken software out there that
gives HELO as a short, unqualified, non-existent or otherwise weird name.
I don't have a lot of data to back it up... I have just heard from others
in passing that HELO checking can be good, but currently requires a lot of
white-listing and exceptions.
Who knows? Perhaps HELO checking and enforcement is incredibly important.
It could be. I just don't have any data to back that up.
GC> However, some users have reported that they get really great results
GC> from...
We need to be very, very careful about _any_ statement beginning with
language like this. There have been many "localized" effects in the
control of spam, but nothing has had any global effect at reducing spam.
Therefore, generalizing from prior experience in spam control can be
very misleading. Often, something that works in small, local
environments, does not scale to the global Internet.
Point well taken. I would agree with this.
There are a number of folks who have localized solutions supported by
analyzing their own data flow, but a lot of data about "the whole picture"
is not really known or well-measured.
About the only thing we can do about it is 1. a lot more research among
many parties, or 2. make some educated guesses and then test them out.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>