Re: Input on identities

[Yakov Shafranovich <research@xxxxxxxxxxxxxxx>]

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