Aredridel wrote:
HELO checking would entail changes in receiving and sending MTAs for
using a TLD as a HELO parameter; and in the receiving MTA for checking
that parameter. This might be mitigated by already existing procedure to
use the machine's name but this would entail publishing records for the
subdomain if the FQDN is a subdomain. If filtering is done past the
initial MTA (SpamAssasin for ex.), than some form of "received" header
parsing would be needed to extract the HELO prompt which would not be
foolproof; IF MARID checking is desired at that layer.
Very true: easy and lightweight, but in my estimation, not as effective
as MAIL FROM would be.
Benefits:
* All machines would use a valid domain to send mail
* Verifiable that it is an authorized MTA for the domain it claims to
be
Possible cons:
* No identity as related to the message itself -- such a system would
make a very weak foundation to base other checks on, unless one were
restrict MAIL FROM or From: to be part of the same domain as the
HELO, which is, I think, completely unreasonable.
You are correct! The HELO argument gives you the identity of the MTA,
not the sending domain. A single SMTP transaction under a single HELO
domain can be in theory used to transfer messages for unlimited number
of sender and receiver domains. Of course that means that there is less
data to handle than MAIL FROM which is why the configuration complexity
is smaller.
What makes HELO checks interesting is that you can base
reputation/accreditation/trust stuff on top of it just like with MAIL
FROM. However, in theory there are less MTAs than domains, so the amount
of data stored with such systems should be less for HELO checking.
With in-addr.arpa, no changes are needed at the sender's MTA or MUA. The
only changes that are needed is the receiving MTA which will evaluate
the information at connection time just like RBL info is used today by
some systems.
What worries me the most about this sort of system is that it again
makes two classes of citizens on the net: Those who have end-to-end IP
connectivity, and those who have restrictions placed on what services
they may run.
There is an ongoing debate about that on the IETF list. Speficially,
people have been arguing that someone who is paying $20 or $30 a month
for IP connectivity is not really getting full service, while they may
think they do. The following draft explains things a bit:
http://www.ietf.org/internet-drafts/draft-klensin-ip-service-terms-00.txt
Yakov