spf-discuss
[Top] [All Lists]

RE: [spf-discuss] Question on a unified policy record approach

2005-09-05 12:53:16
From: Alex van den Bogaerdt 
[mailto:alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net]
Sent: Sunday, September 04, 2005 1:58 AM

<...>

One host. Multiple interfaces. Each interface has its own name:

(I'm using the 10/8 network as example addresses; of course on the
internet other addresses need to be used)

jupiter.example.org       A   10.0.0.1
jupiter-eth1.example.org  A   10.1.0.1
jupiter-qw0.example.org   A   10.2.0.1

Suppose the primary hostname for this box is jupiter.example.org.
Suppose the SMTP connection is made via jupiter-qw0.example.org.
i.e. the connecting client uses address 10.2.0.1

This client (jupiter.example.org) has no choice but to say
"EHLO jupiter.example.org." (or the HELO equivalent).

However, 10.2.0.1 resolves to jupiter-qw0.example.org, not to
jupiter.example.org

This is a particularly interesting case if all the addresses are routable.
However, I don't agree with your interpretation of the intended result.
What we have here is one node with a routable IP using another node with a
routable IP as a gateway or simple pass-through proxy (no NAT).  In that
case, the sender _knows_ that they are giving conflicting information to the
SMTP server at the other end, which I would consider forgery.  If this is an
acceptable method of relaying/gatewaying, then this use case removes the
argument for having _any_ requirements on the EHLO parameters.  If you can't
reject when the SMTP client claims a forged identity (FQDN and IP do not
match:  FQDN is a lie), what's the point of requiring SMTP clients to
provide an accurate identity?

There is no expectation that the IP of jupiter-qw0.example.org is even in a
related netblock to the IP of jupiter.example.org, nor must the ASN's be
related nor must any of the former be related by ownership.  With this
amount of laxness, in the general case, it is hopeless for the SMTP server
to corroborate the correctness of the FQDN given in the EHLO command.
Though not specifically mentioned anywhere that I can find, this is clearly
against the spirit of the RFC.

While "pass-through" proxying of service requests without using NAT is
harmless for some services, it is _not_ appropriate for SMTP.  What I think
is appropriate here is that jupiter.example.org submit its mail to
jupiter-qw0.example.org for relay (or gatewaying, if you prefer) to the
internet.  While the operators of example.org may find this a minor
inconvenience, we can no longer condone EHLO FQDN forgery.  By acting as a
non-vigilant pass-through proxy, jupiter-qw0.example.org is the machine
committing forgery.  It is presenting the SMTP EHLO command to a server
using a FQDN that does not belong to it.  This may be a direct result of the
network setup of example.org and is clearly not malicious, but the end
result is still forgery, which is unacceptable.  The sender has no right to
expect that connection to be accepted by the SMTP server.  That leads to the
real conundrum of the next requirement below.



Your statement (FQDN that resolves to connect IP) is wrong. It assumes
this client will say "EHLO jupiter-qw0.example.org" but that is simply
not allowed by RFC 2821.

There is a reason the following is included in RFC 2821:
"
  An SMTP server MAY verify that the domain name parameter in the EHLO
  command actually corresponds to the IP address of the client.
  However, the server MUST NOT refuse to accept a message for this
  reason if the verification fails: the information about verification
  failure is for logging and tracing only.
"

There may well be a reason for this paragraph, but I don't think it is the
above (ab)use case.  While I have no insight into the motivations of the
folks responsible for 2821, my guess is that they are simply going too far
with the "be strict in what you send and liberal in what you accept"
philosophy.  While they want to codify what we consider best practices
today, they also have the burden to not break too much mail delivery.  I
don't pretend this is easy.  The concept "be liberal in what you accept" is
reasonable in a benign, controlled environment.  It still made a lot of
sense when 1123 was written.  It is _not_ a reasonable engineering approach
for an exposed interface in a hostile environment, which describes email
exchange today.

I'm not criticizing 1123.  What I am saying is that any document that
updates the two-decades old 821 should recognize the bona fide needs of the
SMTP server to somehow validate the identity of the SMTP client requesting a
connection.  RFC2821 already requires SMTP clients to give FQDN's or address
literals as an argument.  Perhaps even the address literal exception is no
longer reasonable, I don't know.  What does appear clear is that RFC2821
intends for SMTP clients to accurately identify themselves.  What use is
this requirement if SMTP servers MUST NOT reject connections when the client
does not comply?


--

Seth Goodman

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

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