Re: Submission identifiers

[John C Klensin <[e-mail]>]

--On Monday, January 26, 2009 7:25 PM -0700 David MacQuigg
<[e-mail]> wrote:

>...
>> What are they supposed to use for the EHLO parameter if it is
>> important enough to mean the difference between delivery or
>> not?
> 
> This is a good case.  I think we can include Steve's example
> as a sub-case, since he has a static IP address from his ISP.
> 
> The solutions in this case include the three suggested for the
> roaming laptop, plus another option.  Get a static IP address
> from your ISP.  In my office I have a small network behind a
> NAT with one external address.  My ISP charges $10 per month
> for the static IP.  Last I checked, the phone company price
> was the same.
>...

David, situations about static IP addresses differ around the
world.  In many places, static IP addresses are not available at
all, at any price, unless one subscribes to a "business"
account... with "business" accounts costing five to ten times as
much as "residential" ones, sometimes with fewer services. 

I expect static addresses, and non-NAT addresses more
specifically, will get progressively harder to get as we move
into the IPv4 endgame.  I also expect that, unless prevented by
regulators or morals, some ISPs will take advantage of scarcity
by raising the price.  Of course, if the advent of IPv6 really
eliminates the use of private-space addresses on servers
communicating with the public Internet, the problem Paul is
concerned about will largely disappear (I'm not holding my
breath).
 
> By the way, I don't use my static IP for sending mail.  For
> reliable delivery, I relay my outgoing mail through a Giant
> Provider, not because of authentication problems, but simply
> that my domain is too small to have any clout with receivers.

The question, IMO, isn't whether the path of least resistance is
to give up on individual servers in favor of Giant Providers.
Nor is it about whether some people's lives would be easier if
servers using private address space behind NAT always used
submission servers that have public addresses.  It is about
whether we try to change the protocol to effectively _require_
one or the other or both.  My personal opinion is that such a
requirement would be a bad idea for several reasons.  However,
what is more important in this particular discussion is that it
would represent a sufficient change in requirements for a server
to conform to the standard to require a reset to Proposed.
Perhaps that would be worthwhile, but it isn't something that
you will see in any 5321bis for which I'm editor (not
necessarily because I'm being resistant, but because I will lose
interest).

>...
> I guess this discussion has about run its course, so I'll
> summarize.  We've narrowed the question to just whether SMTP
> should drop the requirement that receivers MUST NOT reject
> apparently forged helonames.  The suggested language for a
> change was:
> 
>   An SMTP server MAY reject a mail session if a domain name
> argument in   the EHLO command does not actually correspond to
> the IP address of the   client.  Clients that are unable to
> establish this correspondence MUST   NOT provide an invalid
> domain name argument.

Thanks for stating this clearly and providing text.  Note,
however, that "correspond to the IP address of the client" is
ambiguous.  For example, do you intend forward mapping or
reverse mapping?  If the client is multihomed, _exactly_ what
does "correspond" mean?

> The claimed benefit was that a currently useless and
> frequently abused parameter, the heloname, could then become
> useful in rejecting forgeries, and that would motivate
> legitimate senders to take it seriously.  This in turn could
> lead to large numbers of receivers making good use of the
> heloname, whitelisting legitimate domains, etc.  Eventually
> almost all legitimate mail would go this route, and only a
> small fraction would have to go through a spam filter,
> reducing losses, and improving the reliability of email
> communications.
> 
> The claimed reason for not making this change was that it
> would be too hard on some small fraction of legitimate
> senders.  Three cases were presented. 1) The small office with
> a dynamically-assigned IP address. 2) The roaming laptop.
> 3) The digital camera.
> 
> The solutions considered too difficult were:
> 1) Get a static IP address for the transmitter in the small
> office. 2) Relay through a transmitter with an established
> identity and reputation. 3) Authorize the entire block of
> addresses that might be dynamically assigned to the
> transmitter. 4) Use an address literal, meaning - please
> accept this session without a HELO ID.
> 
> Have I missed anything?

I don't think so, as long as it is clearly understood that this
does two things:

(i) Defines a domain name argument that does not match the
public Internet address of the sender as "invalid" --  thereby
de facto preventing most SMTP clients that are using private
address space behind at NAT from sending mail -- even if that
domain name conveys accurate information about the sending
system.

(ii) Forces people toward use of IP literals, even IP literals
in private address space (i.e., that convey little information),
when domain names might make the sender more identifiable and
more easily contacted.

    john