On Sun, Sep 04, 2005 at 01:08:23PM -0400, Stuart D. Gathman wrote:
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
The PTR records are irrelevant. We are only talking about
the EHLO name resolving to the connect ip, NOT the connect ip
resolving to the EHLO name.
OK. In my book, PTR will have to point to domain as well but indeed,
this doesn't matter.
The A records ought to look like:
jupiter.example.org A 10.0.0.1
jupiter.example.org A 10.1.0.1
jupiter.example.org A 10.2.0.1
jupiter-eth1.example.org A 10.1.0.1
jupiter-qw0.example.org A 10.2.0.1
Ought to? No. It can, but it doesn't ought. There may be valid reasons
not to do this and as such you cannot rely on it.
An example: if I resolve jupiter.example.org I should not be returned
10.1.0.1 and 10.2.0.1 for whatever reason. Maybe because I cannot reach
them. Yes, jupiter can connect to me from those addresses, maybe only
for SMTP, maybe only outbound. I don't know. It doesn't matter.
and then the EHLO is compliant with my reading of the RFC.
If, and only if, you can rely on all addresses being returned when hostname
is looked up. I seriously doubt that (as discussed above).
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.
"
Exactly. This confirms my interpretation that EHLO is SUPPOSED to
correspond with the connect ip. Currently, I never refuse a
I would have expected "SHOULD NOT" if your version was to be supported.
Alex
-------
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