[Top] [All Lists]

Re: Submission identifiers

2009-01-27 03:18:08

--On Monday, January 26, 2009 7:25 PM -0700 David MacQuigg
<david_macquigg(_at_)yahoo(_dot_)com> wrote:

What are they supposed to use for the EHLO parameter if it is
important enough to mean the difference between delivery or

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
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

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

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

(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.


<Prev in Thread] Current Thread [Next in Thread>