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?
As I understand verified - yes. And if the HELO value were verifiable
it would help
with tracking the source of spam. I also said I think that the
verification key or
sig or value should have a 'and this is a proxy MTA for host-x' to aid
in the tracking
to the source host especially when it comes from a virtual host or
co-hosted domain
inside the ISPs intranet without the ISPs permission or knowledge.
My customer has a zero spam rule. However it can take hours of manual
log checking
sometimes to figure out which of the 2,000+ virtual hosts sent the spam.
And the
first step is always - did it really come from this MTA?
I do not think that HELO validation would stop or slow spam directly. I do
think it would allow them to be shut down faster.
What would inhibit spammers from simply using unverifiable domains in
HELO?
Is that not the opposite of the proposal? I thought the proposal was
that they were verified
or you can toss them. As I understand it, the idea was to have some sort
of key or sig
that could be checked and trusted. If that were in place and it was not
verified or not
trusted then you could toss it.
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?
Who are the legitimate unverifiable MTAs? I do not know of any.
Looking in my inbox and spam logs, almost all of the spam sent a bogus
HELO value.
Many MTAs can still accept email without ever being sent a HELO command.
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.
Stating the obvious: HELO tracks the MTA sender of the spam. MAIL FROM
can be utterly unrelated to that value in spam. The people that intend
to send
spam are who I would blacklist. The hacked sites (HELO value again) would
need feedback or blacklisted. The content site of the spam is another to
blacklist.
The value in the MAIL FROM is often bogus.
So, are you saying you want to have a sig or key that verified the From:
value 1st?
Like S/MIME. I agree. But Dave's point of setting up a HELO validation
would
be easier to get implemented, add traceability to the spam source, and
be 'a' step
towards solving a problem of identifying the spammer.
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.
I think that it would only help with traceability. The only
accountability it adds is that you can
blacklist the verified source.
...
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug(_at_)Royer(_dot_)com | Office: (208)520-4044
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards
smime.p7s
Description: S/MIME Cryptographic Signature