On Tue, Sep 06, 2005 at 04:08:58PM +0100, paddy wrote:
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
I am just asking a question: what is it that you are trying to prove. We
were talking about HELLO and SPF, you suddenly talk about ptr.
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.
This is valid:
<connection from ip-address>
ip-address PTR domain1.
domain1. A ip-address
HELO domain2
MAIL FROM: <lhs(_at_)domain3>
In the SPF record for domain2: +ip4:ip-address
In the SPF record for domain3: +ip4:ip-address
domain1 does not play a role, unless it is mentioned in stead of the
IP address:
In the SPF record for domain2: +a:domain1
In the SPF record for domain3: +a:domain1
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 ?
Sometimes you want a client to be able to connect to all interfaces.
A single lookup returns more than one ip-address in such a case.
Sometimes you do not want a client to be able to connect to all
interfaces. You just return one ip-address (and probably have
a different name per interface).
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 ?
No, it is not. I never said that (at least not in this discussion, and also
not as far as I remember). I said that the entire check doesn't play a role
as it is not to be used for rejection and it is not used for the SPF example
I gave.
_If_ you want to check a domain parameter, you better check it properly and
then of course you need to verify both A and PTR, not just for their presence
but also look if they match.
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 ?
I wrote that I used rfc1918 addresses as an example. rfc1918 addresses
must not be used on the internet. I wanted to make clear that I knew this.
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).
Look a couple of messages back.
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