Re: Input on identities

[Doug Royer <Doug@xxxxxxxxx>]

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@xxxxxxxxx                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                              | Cell:   (208)520-4044

             We Do Standards - You Need Standards

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature