On Tue, Sep 06, 2005 at 03:36:42PM +0200, Alex van den Bogaerdt wrote:
On Tue, Sep 06, 2005 at 12:09:46PM +0100, paddy wrote:
granted, but it does not replace the check of a ptr which has potential
to curb forgery the other way around.
What are you trying to prove? I think you are mixing up technologies.
Apologies if I came across a bit strong. I've never really stopped to
question the practice EHLOing with the domain that matches the PTR, and
I've never stopped to consider the multi-homed case. I suppose my
interest is to better understand how those technologies interact.
I couldn't immediately see a reason not to have both, which would be
complementary. I'm still having trouble seeing how spf mitigates not
EHLOing that way, but if as you say that is not always possible/desirable,
then I can see how it is better than nothing.
Is their a reason why the PTRs for 10.{1,2,3}.0.1 could or should not
all resolve to a single name ?
Yes. And this depends on the situation. You cannot count on it
either way as both situations can be valid.
please elaborate ?
But as I said before: this doesn't matter. The example I gave doesn't
need _any_ lookup of hostnames.
Agreed PTRs didn't appear in your original example. I read them in
unconsciously. Perhaps because they seem like the juicier part of the
problem to me. My sincere apologies if I'm wasting your time with this.
considering
In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available),
Is it your interpretation that
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
refers soley to the A record and not to the PTR ?
Or is it that the problems are pretty much the same ?
Elsewhere in the thread you seem to suggest that if, for example, one of
the IPs on this machine is an rfc1918 address, then this would create a
problem ?
Apologies, but I don't see why.
Say that 10.3.0.1 is the rfc1918 (internal, off-internet) address, and the
others are internet addresses. Surely you return just the two A records
when queried from the internet side ? Is there another variation on this
situation you had in mind that is not amenable to such a solution ?
I certainly agree with you that
"However, the server MUST NOT refuse to accept a message for this
reason if the verification fails"
strongly suggests that there may be situations in which it is impossible
or undesirable to EHLO with a verifiable domainname (supporting a
legacy doesn't seem like a likely reason), but I've yet to see an explanation
or example that I found compelling (but that may be just me being dense).
Once again, I apologise and thanks for sticking with it. I'm simply
trying to get my head around it!
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
-------
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