John Gardiner Myers <jgmyers(_at_)proofpoint(_dot_)com> wrote:
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?
Not quite. It's a key which permits the recipient to make the
sender more accountable. That encompasses a little more than making
better abuse reports.
What would inhibit spammers from simply using unverifiable domains in
HELO?
On the protocol side, nothing.
On the implementation/deployment side, lots. Recipients may treat
unverifiable domains with great suspicion.
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?
That's one. Any abuse reports involving IP's not in their
authorization records can be *trivially* discarded or bounced as being
forged.
How many people does AOL have handling abuse reports? Their costs
may decrease substantially.
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.
Perhaps. Another issue is that SMTP confuses control & data information.
When TCP SYN's to are sent to closed ports, the network stack
doesn't send a "TCP NACK" back. It sends an "ICMP Port Unreachable."
SMTP uses the "user message delivery" mechanism to send bounce
messages. This makes it more difficult to handle bounces, than if
they used a seperate NACK method.
Alan DeKok.