Mailing List Archive

Falling back to parent domains...
Hi there - we're using jSPF to evaluate 1-2 million messages a day... i
understand that part of my issues are jSPF-related, and i'll follow up
as appropriate with them, but i'm curious about the issue of
parent-domain fallback in SPF in general. I see that previous versions
of RFC 4408 mention it, but the final draft does not seem to. (am i
correct, there?)

Basically, jSPF is giving the result "none" for
spoofer@orders.amazon.com since orders.amazon.com has no SPF/TXT
records. This is correct, of course, but i'm wondering about the issues
around parent-domain fallback. Is it commonly done by SPF clients? What
is the controversy, if any, besides extra DNS lookups?

Thanks!
-c


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
On Sun, Mar 7, 2010 at 19:16, <spfhelp@caseyconnor.org> wrote:
> Hi there - we're using jSPF to evaluate 1-2 million messages a day... i
> understand that part of my issues are jSPF-related, and i'll follow up as
> appropriate with them, but i'm curious about the issue of parent-domain
> fallback in SPF in general. I see that previous versions of RFC 4408 mention
> it, but the final draft does not seem to. (am i correct, there?)
>
> Basically, jSPF is giving the result "none" for spoofer@orders.amazon.com
> since orders.amazon.com has no SPF/TXT records. This is correct, of course,
> but i'm wondering about the issues around parent-domain fallback. Is it
> commonly done by SPF clients? What is the controversy, if any, besides extra
> DNS lookups?

http://www.openspf.org/FAQ/The_demon_question

Otherwise where do you stop? If there was no SPF record for
amazon.com should you then fall back to the .com SPF record?

--
Please keep list traffic on the list.

Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
Thanks for the reply and the FAQ link that i missed somehow...

Thus, anyone can spoof arbitrary subdomains from places such as:

microsoft.com
ebay.com
amazon.com
paypal.com
openspf.org

...etc etc... Unless i'm missing something (entirely possible), since
none of them have wildcard TXT records?

Thanks,
-c

Rob MacGregor wrote:
> On Sun, Mar 7, 2010 at 19:16, <spfhelp@caseyconnor.org> wrote:
>
>> Hi there - we're using jSPF to evaluate 1-2 million messages a day... i
>> understand that part of my issues are jSPF-related, and i'll follow up as
>> appropriate with them, but i'm curious about the issue of parent-domain
>> fallback in SPF in general. I see that previous versions of RFC 4408 mention
>> it, but the final draft does not seem to. (am i correct, there?)
>>
>> Basically, jSPF is giving the result "none" for spoofer@orders.amazon.com
>> since orders.amazon.com has no SPF/TXT records. This is correct, of course,
>> but i'm wondering about the issues around parent-domain fallback. Is it
>> commonly done by SPF clients? What is the controversy, if any, besides extra
>> DNS lookups?
>>
>
> http://www.openspf.org/FAQ/The_demon_question
>
> Otherwise where do you stop? If there was no SPF record for
> amazon.com should you then fall back to the .com SPF record?
>
>


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
spfhelp@caseyconnor.org wrote:

>Thanks for the reply and the FAQ link that i missed somehow...
>
>Thus, anyone can spoof arbitrary subdomains from places such as:
>
>microsoft.com
>ebay.com
>amazon.com
>paypal.com
>openspf.org
>
>...etc etc... Unless i'm missing something (entirely possible), since
>none of them have wildcard TXT records?
>
Don't accept mail from domains that don't exist. If you don't, this is not an issue.

Scott K

-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
On Sun, Mar 7, 2010 at 20:22, <spfhelp@caseyconnor.org> wrote:
> Thanks for the reply and the FAQ link that i missed somehow...
>
> Thus, anyone can spoof arbitrary subdomains from places such as:
>
> microsoft.com
> ebay.com
> amazon.com
> paypal.com
> openspf.org
>
> ...etc etc... Unless i'm missing something (entirely possible), since none
> of them have wildcard TXT records?

Any correctly configured mail server will refuse, as Scott said, email
from domains that don't exist. If your mail server accepts email from
domains that don't exist then either it's very old and in bad need of
an upgrade, or the administrator deliberately chose to configure it
that way.

--
Please keep list traffic on the list.

Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
At 12:42 08/03/2010 Monday, Rob MacGregor wrote:
>On Sun, Mar 7, 2010 at 20:22, <spfhelp@caseyconnor.org> wrote:
>> Thanks for the reply and the FAQ link that i missed somehow...
>>
>> Thus, anyone can spoof arbitrary subdomains from places such as:
>>
>> microsoft.com
>> ebay.com
>> amazon.com
>> paypal.com
>> openspf.org
>>
>> ...etc etc... Unless i'm missing something (entirely possible), since none
>> of them have wildcard TXT records?
>
>Any correctly configured mail server will refuse, as Scott said, email
>from domains that don't exist. If your mail server accepts email from
>domains that don't exist then either it's very old and in bad need of
>an upgrade, or the administrator deliberately chose to configure it
>that way.

additionally mail servers will accept mail from existent sub-domains that the domain owner has
CHOSEN not to publish spf records for, as that is the domain owners specified{lack of} policy

ie www.amazon.com which is one of the few above with an A record so yes their lack of spf policy means they choose to allow anyone to forge user@www.amazon.com {chose through omission, just like domains publishing no spf at all}

but for example www.openspf.com has an spf {curiously allowing the domain within mail, most likely for HELO use {but a bit strange to use that hostname in a helo}

www.microsoft.com is an alias thus has no A or MX and should be refused by all mailservers
{crazily it points at microsoft.com and thus some dodgy libraries/mta's that follow aliases will allow user@www.micr.. and use the mx's from and spf from microsoft.com which I doubt they really wanted}



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
>>Any correctly configured mail server will refuse, as Scott said, email
>>from domains that don't exist. If your mail server accepts email from
>>domains that don't exist then either it's very old and in bad need of
>>an upgrade, or the administrator deliberately chose to configure it
>>that way.
>
> additionally mail servers will accept mail from existent sub-domains that
> the domain owner has
> CHOSEN not to publish spf records for, as that is the domain owners
> specified{lack of} policy

> ie www.amazon.com which is one of the few above with an A record so yes
> their lack of spf policy means they choose to allow anyone to forge
> user@www.amazon.com {chose through omission, just like domains publishing
> no spf at all}

zone, not domain.

http://www.openspf.org/DNS#Domain


> but for example www.openspf.com has an spf {curiously allowing the domain
> within mail, most likely for HELO use {but a bit strange to use that
> hostname in a helo}

RFC5321 section 2.3.5:
The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.

So, if the host's name would be www.openspf.org, then it MUST use that name
when it sends mail. This said, there is a configuration problem, because
the host's official name is openspf.org, not www.openspf.org ...

> www.microsoft.com is an alias thus has no A or MX and should be refused by
> all mailservers
> {crazily it points at microsoft.com and thus some dodgy libraries/mta's
> that follow aliases will allow user@www.micr.. and use the mx's from and
> spf from microsoft.com which I doubt they really wanted}

RFC5321 section 2.3.5 again:

For example, a domain may refer to an alias (label of a
CNAME RR) or the label of Mail eXchanger records to be used to
deliver mail instead of representing a host name.
[...]
In other words, names that can
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
in Section 5) are permitted, as are CNAME RRs whose targets can be
resolved, in turn, to MX or address RRs. Local nicknames or
unqualified names MUST NOT be used.

I am aware that, officially, RFC5321 is not yet the standard. But de facto
it is. At the time of RFC821 little was known about the domain name system,
CNAME isn't even mentioned in it. It does talk about aliases, but only in
relation to host names. You were discussing mailbox names, which (at present
day) need not to be related to hostnames.

IMHO strictly speaking, "HELO alias.domain.example" is not allowed, but
"rcpt to:<user@alias.domain.example>" is specifically allowed by RFC5321.

HTH
Alex



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
>
>>ie www.amazon.com which is one of the few above with an A record so yes
>>their lack of spf policy means they choose to allow anyone to forge
>>user@www.amazon.com {chose through omission, just like domains publishing
>>no spf at all}
>
>zone, not domain.

ok a NO domain they have no spf for the single domain www.amazon.com this makes no inferred or implied assumptions about any/all of the other domains within the amazon.com zone


>http://www.openspf.org/DNS#Domain
>
>
>>but for example www.openspf.com has an spf {curiously allowing the domain
>>within mail, most likely for HELO use {but a bit strange to use that
>>hostname in a helo}
>
>RFC5321 section 2.3.5:
>The domain name given in the EHLO command MUST be either a primary
> host name (a domain name that resolves to an address RR) or, if
> the host has no name, an address literal, as described in
> Section 4.1.3 and discussed further in the EHLO discussion of
> Section 4.1.4.
>
>So, if the host's name would be www.openspf.org, then it MUST use that name
>when it sends mail. This said, there is a configuration problem, because
>the host's official name is openspf.org, not www.openspf.org ...

you fail to read the quoted section where it says
"a primary host name (a domain name that resolves to an address RR)"

ie a hostname with an A record {as opposed to an alias that has only a CNAME}
this effects in no way any/all other primary host names the ip address may also have

the mis-reading of the above by many mail admins is the cause of so much idiocy in the helo names they use


>>www.microsoft.com is an alias thus has no A or MX and should be refused by
>>all mailservers
>>{crazily it points at microsoft.com and thus some dodgy libraries/mta's
>>that follow aliases will allow user@www.micr.. and use the mx's from and
>>spf from microsoft.com which I doubt they really wanted}
>
>RFC5321 section 2.3.5 again:
>
>For example, a domain may refer to an alias (label of a
> CNAME RR) or the label of Mail eXchanger records to be used to
> deliver mail instead of representing a host name.
>[...]
>In other words, names that can
> be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
> in Section 5) are permitted, as are CNAME RRs whose targets can be
> resolved, in turn, to MX or address RRs. Local nicknames or
> unqualified names MUST NOT be used.
>
>I am aware that, officially, RFC5321 is not yet the standard. But de facto
>it is. At the time of RFC821 little was known about the domain name system,
>CNAME isn't even mentioned in it. It does talk about aliases, but only in
>relation to host names. You were discussing mailbox names, which (at present
>day) need not to be related to hostnames.
>
>IMHO strictly speaking, "HELO alias.domain.example" is not allowed, but
>"rcpt to:<user@alias.domain.example>" is specifically allowed by RFC5321.
>
>HTH
>Alex
>
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/
>Powered by Listbox: http://www.listbox.com



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
----- Original Message -----
From: "alan" <spfdiscuss@alandoherty.net>
To: <spf-help@v2.listbox.com>; <spf-help@v2.listbox.com>
Sent: Monday, March 08, 2010 7:03 PM
Subject: Re: [spf-help] Falling back to parent domains...


>
>>
>>>ie www.amazon.com which is one of the few above with an A record so yes
>>>their lack of spf policy means they choose to allow anyone to forge
>>>user@www.amazon.com {chose through omission, just like domains publishing
>>>no spf at all}
>>
>>zone, not domain.
>
> ok a NO domain they have no spf for the single domain www.amazon.com this
> makes no inferred or implied assumptions about any/all of the other
> domains within the amazon.com zone

I was referring to, what I believed to be, your use of "domain" when you
were referring to "domain" (read: zone) amazon.com. All domains but one are
subdomains. A zone contains domains, not subdomains.

Why is this important? Because many people _think_ that they did their job
because they configured an SPF policy for their "domain" (read: zone). That
is not the case. SPF needs to be configured for any domain which could be
used in email.


>>So, if the host's name would be www.openspf.org, then it MUST use that
>>name
>>when it sends mail. This said, there is a configuration problem, because
>>the host's official name is openspf.org, not www.openspf.org ...
>
> you fail to read the quoted section where it says
> "a primary host name (a domain name that resolves to an address RR)"

and does www.openspf.org resolve to an address RR or does it not?

That domain is not "the" official hostname for the box, but for now assume
that dig +short -x 76.79.58.174 did return www.openspf.org, then it would be
okay.


> ie a hostname with an A record {as opposed to an alias that has only a
> CNAME}
> this effects in no way any/all other primary host names the ip address may
> also have
>
> the mis-reading of the above by many mail admins is the cause of so much
> idiocy in the helo names they use

A hostname is a domain name, but a domain name does not need to be a
hostname.

user@${domainname} is valid, even if ${domainname} is not a hostname.

EHLO ${domainname} is only valid if ${domainname} is a hostname.

In the past I also forgot about user@${CNAME}. Which is weird, because I
used one for many years. qmail has a problem with it. Postfix does not.
Whatever gmail is using, does not. I don't know about the rest.




-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
At 19:05 08/03/2010 Monday, Alex van den Bogaerdt wrote:
>----- Original Message ----- From: "alan" <spfdiscuss@alandoherty.net>
>To: <spf-help@v2.listbox.com>; <spf-help@v2.listbox.com>
>Sent: Monday, March 08, 2010 7:03 PM
>Subject: Re: [spf-help] Falling back to parent domains...
>
>
>>
>>>
>>>>ie www.amazon.com which is one of the few above with an A record so yes
>>>>their lack of spf policy means they choose to allow anyone to forge
>>>>user@www.amazon.com {chose through omission, just like domains publishing
>>>>no spf at all}
>>>
>>>zone, not domain.
>>
>>ok a NO domain they have no spf for the single domain www.amazon.com this makes no inferred or implied assumptions about any/all of the other domains within the amazon.com zone
>
>I was referring to, what I believed to be, your use of "domain" when you were referring to "domain" (read: zone) amazon.com. All domains but one are subdomains. A zone contains domains, not subdomains.

i know this, you understanding was erronious, why are you continuing debating the point, i meant what i typed nothing more
i have no issue understanding the difference i referred to the domain www.amazon.com
not the zone and domain amazon.com or any other domains within the zone such as xxx.amazon.com or any other

>Why is this important? Because many people _think_ that they did their job because they configured an SPF policy for their "domain" (read: zone). That is not the case. SPF needs to be configured for any domain which could be used in email.

i know its important, that is why i type what i mean and mean what i type {and need no mis-clarification that changes entirely my meaning}
I already know every domain with an MX or A {also AAAA} needs its own SPF record,
I already advise every person on here of this, i and any of my customers/friends/colleagues already DO

>>>So, if the host's name would be www.openspf.org, then it MUST use that name
>>>when it sends mail. This said, there is a configuration problem, because
>>>the host's official name is openspf.org, not www.openspf.org ...

this is as i pointed out not a configuration problem
{its not the way i would do it but it also dosn't trip any alarms}


>>you fail to read the quoted section where it says
>>"a primary host name (a domain name that resolves to an address RR)"
>
>and does www.openspf.org resolve to an address RR or does it not?

yes it does {not related to my point}
{i was not saying its invalid, i was saying why would you chose to helo as www.anything when www.anything is a domainname primarily used for website role, better to setup and use somethingelse.openspf.org specifically for the HELO role}
same as i would setup somethingelseagain.openspf.org for ptr>A>ip verification

thus leaving the domain openspf.org free to be used for spf, mx and potentially pointed at whatever machine{s} {for webusers to be 301 redirected to www.openspf.org}
and simmilarly www.openspf.org free to be moved from mirror to mirror without effecting mail-flow from the machine it is currently pointed at

domainnames should {when possible} be used for one role it makes future expansion possible

>That domain is not "the" official hostname for the box, but for now assume that dig +short -x 76.79.58.174 did return www.openspf.org, then it would be okay.

it would be ok for a helo regardless of the name used in the PTR
{it is ok for a helo as long as it has an A {or nowdays AAAA also} it is only not allowed if it is an alias {has no A because it has a cname/mx or some other non A record only}

PTR doesn't need to = HELO
{though your logic is mis-used by many to foolishly try to force people to use this bad idea}
PTR needs to resolve to an A the A resolves back to the IP {proves ip is correctly setup and ownership} FCRDNS
HELO needs to resolve to an A {<thats all RFC requires,} most receivers {including me unless user whitelisted} also demand that the A resolves back to the IP {or helo has spf extending the scope to more than 1 ip {clusters with shitty DNS hosting}}

if FCRDNS name is used for HELO it means that malware on the same IP {usually due to NAT} will also helo with a name that is expected and be regarded as valid from that IP {hardly a good idea}, thus bad standard to promote ever

this is why well setup senders
have a ptr >a>ip of xxxx.domain.tld {proving tie between domain.tld and IP}
helo as
yyy.domain.tld {which also has an a record pointing at IP, thus is valid as HELO, and not a forgery due to test above prooving that the parent domain of both owns the ip}

have an spf for xxxx.domain.tld of "v=spf1 -all" to block malware on the same ip {that can lookup its own ptr}
and have an spf for yyy.domain.tld of at least "v=spf1 a -all" to allow that name to be verified as usable in helo {thus validating the source application not just IP}

{a bad idea is to have FQRDNS of xxx.domain1.tld and helo as yyy.domain2.tld as there is no way to {programatically}know that the owner of xxx.domain1.tld {the traceable owner of the IP} is even aware of the application sending as yyy.domain2.tld as domain2.tld could conceivably belong to the bot-herder and thus even pass spf}

>>ie a hostname with an A record {as opposed to an alias that has only a CNAME}
>>this effects in no way any/all other primary host names the ip address may also have
>>
>>the mis-reading of the above by many mail admins is the cause of so much idiocy in the helo names they use
>
>A hostname is a domain name, but a domain name does not need to be a hostname.

i know that {i have been administering DNS for many many years}

>user@${domainname} is valid, even if ${domainname} is not a hostname.
>
>EHLO ${domainname} is only valid if ${domainname} is a hostname.

i know that too
{but the point is a hostname does not have to be the same hostname used within the PTR,
and in these modern times SHOULD NOT BE
senders with a {verified to be same ip} helo in same parent domain as FCRDNS that is different to the FCRDNS {if both have spf showing the admin understands the problem he is avoiding}
get past a huge number of anti-bot checks in newer MTA's, {as a bot cannot conceivably guess the allowed hostname from ip}

any where helo=FCRDNS automatically are suspect as most botspam will have this character if from a host with FCRDNS
any where helo=top-level-domain.tld is equally unlikely to be a competent admin and is thus scrutinized

{all these mis-configurations are common, that is no reason to promote the continued use of a bad habit}

you can see it all broken down at
http://www.alandoherty.net/mailservers/


>In the past I also forgot about user@${CNAME}. Which is weird, because I used one for many years. qmail has a problem with it. Postfix does not. Whatever gmail is using, does not. I don't know about the rest.

its totally valid always has been always will





>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/
>Powered by Listbox: http://www.listbox.com



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
>>I was referring to, what I believed to be, your use of "domain" when you
>>were referring to "domain" (read: zone) amazon.com. All domains but one
>>are subdomains. A zone contains domains, not subdomains.
>
> i know this, you understanding was erronious, why are you continuing
> debating the point, i meant what i typed nothing more

I'm not continuing, I just started. Never mind, okay? Aparently we agree.

>>>>So, if the host's name would be www.openspf.org, then it MUST use that
>>>>name
>>>>when it sends mail. This said, there is a configuration problem,
>>>>because
>>>>the host's official name is openspf.org, not www.openspf.org ...
>
> this is as i pointed out not a configuration problem
> {its not the way i would do it but it also dosn't trip any alarms}


dig www.openspf.org

result: 76.79.58.174

dig -x .79.58.17476

result: openspf.org.

dig openspf.org.

result: 76.79.58.174

That was what I was talking about. The offical name of this box is,
apparantly, openspf.org

I believe the official hostname is what "dig -x 79.58.17476" returns,
provided of course that dig openspf.org returns the same IP addres.

>>>you fail to read the quoted section where it says
>>>"a primary host name (a domain name that resolves to an address RR)"
>>
>>and does www.openspf.org resolve to an address RR or does it not?
>
> yes it does {not related to my point}
> {i was not saying its invalid, i was saying why would you chose to helo as
> www.anything when www.anything is a domainname primarily used for website
> role, better to setup and use somethingelse.openspf.org specifically for
> the HELO role}

If the _HOST_ is called spf.openspf.org, then is MUST use its own name in
helo. Not another name, only because some human being thinks it may be
better to use another name.

"www" is no better or worse than "axl", "freddy" or whatever other name.

> {but the point is a hostname does not have to be the same hostname used
> within the PTR,
> and in these modern times SHOULD NOT BE

Okay, I'm willing to agree with you here. What better information than
RFC1035 do you have?

>>In the past I also forgot about user@${CNAME}. Which is weird, because I
>>used one for many years. qmail has a problem with it. Postfix does not.
>>Whatever gmail is using, does not. I don't know about the rest.
>
> its totally valid always has been always will

Are you the same Alan that wrote:

"www.microsoft.com is an alias thus has no A or MX and should be refused by
all mailservers
{crazily it points at microsoft.com and thus some dodgy libraries/mta's that
follow aliases will allow user@www.micr.. and use the mx's from and spf from
microsoft.com which I doubt they really wanted}"

?



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
>>>>>So, if the host's name would be www.openspf.org, then it MUST use that name
>>>>>when it sends mail. This said, there is a configuration problem, because
>>>>>the host's official name is openspf.org, not www.openspf.org ...
>>
>>this is as i pointed out not a configuration problem
>>{its not the way i would do it but it also dosn't trip any alarms}
>
>
>dig www.openspf.org
>
>result: 76.79.58.174
>
>dig -x .79.58.17476
>
>result: openspf.org.
>
>dig openspf.org.
>
>result: 76.79.58.174
>
>That was what I was talking about. The offical name of this box is, apparantly, openspf.org

there is no such thing as "official hostname" , the closest to that would be the name configured on the box itself and returned by the $HOSTNAME variable or hostname command

openspf.org is the FQRDNS name nothing more

>I believe the official hostname is what "dig -x 79.58.17476" returns, provided of course that dig openspf.org returns the same IP addres.
>
>>>>you fail to read the quoted section where it says
>>>>"a primary host name (a domain name that resolves to an address RR)"
>>>
>>>and does www.openspf.org resolve to an address RR or does it not?
>>
>>yes it does {not related to my point}
>>{i was not saying its invalid, i was saying why would you chose to helo as www.anything when www.anything is a domainname primarily used for website role, better to setup and use somethingelse.openspf.org specifically for the HELO role}
>
>If the _HOST_ is called spf.openspf.org, then is MUST use its own name in helo. Not another name, only because some human being thinks it may be better to use another name.

that is BULLSHIT!! plain and simple, its backward ass thinking and nothing to do with the rfc's

>"www" is no better or worse than "axl", "freddy" or whatever other name.

as long as it has an A record it is fine in a HELO, using any hostname* is legit vis a vis the RFC {as quoted above [and originally by you]}

>>{but the point is a hostname does not have to be the same hostname used within the PTR,
>>and in these modern times SHOULD NOT BE
>
>Okay, I'm willing to agree with you here. What better information than RFC1035 do you have?

simple experience of knowing that its programmatically impossible to determine if a connection from a host in 99.99% of static ranges {ones with a ptr allocated to businesses for the express intent of ensuring they can run in-house mta's} originated with the MTA {good} or any random desktop {BAD} if they follow the backward idea that their MTA should helo with its FQRDNS name

if on the other hand they adopt the better practice of HELOing with a hostname other than their FQRDNS {in the same parent domain}
{obviously A record pointing at same ip, spf/csa etc. verifying it is allowed in HELO}
it is immediately distinguishable from the potentially hundreds of infected desk tops on the same network, and due to the obvious due-care-and-attention, of the admin it can be given a much easier time on most further checks.
also by now being able to publish a "deny all" SPF record for the FQRDNS name they also get to inform others that any connections originating on bots {the only hosts that will HELO with this name} are to be rejected

>>>In the past I also forgot about user@${CNAME}. Which is weird, because I used one for many years. qmail has a problem with it. Postfix does not. Whatever gmail is using, does not. I don't know about the rest.
>>
>>its totally valid always has been always will
>
>Are you the same Alan that wrote:
>
>"www.microsoft.com is an alias thus has no A or MX and should be refused by all mailservers
>{crazily it points at microsoft.com and thus some dodgy libraries/mta's that follow aliases will allow user@www.micr.. and use the mx's from and spf from microsoft.com which I doubt they really wanted}"

yes, its an alias thus SHOULD BE REFUSED as a HELO name which is what we are discussing
and as it aliases to a domain with both A and MX records it would still be valid for user@www.microsoft {which their MX's do NOT accept thus is not what they intended}
and as some dodgy implementations of SPF libraries do follow cname-chains to txt/spf records and would therefore mistakenly allow in HELO and in envelope-from {which as i have mentioned was NOT their intent}
and as their microsoft.com spf ends in ~all would allow both unintended uses from everywhere

*hostname or canonical-name
being defined as a domain-name with an A {or AAAA} record
as opposed
to a non-hostname a domain-name without an A {or AAAA} record {cname record pointing to a hostname being a prime example, cname literally meaning alias for this canonical-name}

their is no mystical "real" hostname, neither is connected to the name defined in the PTR {except that the PTR should reference at least one of the hostnames of the IP}




>?
>
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/
>Powered by Listbox: http://www.listbox.com



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
> there is no such thing as "official hostname" , the closest to that would
> be the name configured on the box itself and returned by the $HOSTNAME
> variable or hostname command

And, as the HELO/EHLO command identifies the host, this is the name which
should be used.

> as long as it has an A record it is fine in a HELO, using any hostname* is
> legit vis a vis the RFC {as quoted above [and originally by you]}

That text is to explain the difference between A and CNAME. It does not tell
you that you can use any existing hostname or worse.

Following your line of reasoning, I would also be allowed to use your
hostname... of course I am not.

> that is BULLSHIT!! plain and simple, its backward ass thinking and nothing
> to do with the rfc's

Please make your point without using such language.

>>>{but the point is a hostname does not have to be the same hostname used
>>>within the PTR,
>>>and in these modern times SHOULD NOT BE
>>
>>Okay, I'm willing to agree with you here. What better information than
>>RFC1035 do you have?
>
> simple experience of knowing that its programmatically impossible to
> determine if a connection from a host in 99.99% of static ranges {ones
> with a ptr allocated to businesses for the express intent of ensuring they
> can run in-house mta's} originated with the MTA {good} or any random
> desktop {BAD} if they follow the backward idea that their MTA should helo
> with its FQRDNS name


This is what the RFC, written in these modern times (oct 2008), has to say
about it:

"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), the client SHOULD send an address literal (see Section
4.1.3).
"

What follows from this? A domain which does not have a reverse mapping is
not a meaningful hostname and must not be used as HELO parameter.

It is possible for a host to have more than one name which passes the
A->PTR->same_A test. This could for instance happen on a multi homed host
with different names for each interface. That does still not mean you can
select any of those names.

The HELO parameter identifies the host. It does not identify the interface
used, nor does it identify the organization as some seem to think. There's
nothing wrong with using, say, www.openspf.org (provided that this is a name
which resolves to an address which resolves back to the same name).


>>Are you the same Alan that wrote:
>>
>>"www.microsoft.com is an alias thus has no A or MX and should be refused
>>by all mailservers
>>{crazily it points at microsoft.com and thus some dodgy libraries/mta's
>>that follow aliases will allow user@www.micr.. and use the mx's from and
>>spf from microsoft.com which I doubt they really wanted}"
>
> yes, its an alias thus SHOULD BE REFUSED as a HELO name which is what we
> are discussing

If you were discussing HELO parameters, why did you choose an example of
user@www.microsoft ?

And what is dodgy about following aliases when trying to resolve mailbox
domains?




-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
Last post DECLARING THREAD DEAD
there is no point arguing with the willful ignorant, they will drag you down to their level and beat you with experience.

either read/learn or ignore, but do not mis-educate others into adopting a HELO=MUST=FCRDNS policy as this is damaging to the efforts of all trying to espouse better sender practices, so that eventually receivers can determine {programatically} the good {well run} from the bad {badly run/and ratware}

it took us a long time to educate the world that open-relay was bad, were still working on accept-then-bounce {backscatter} but making headway {many small receivers still doing}, and were trying to get good senders to adopt useful-traceable-verifiable-as-MTA HELO/EHLO to make receivers filtering easier.

using HELO==FCRDNS {in your outgoing} dosn't make your sender bad but also dosn't elevate it above every piece of ratware, thus all mail MUST be subjected to same level of scrutiny from such senders.

requiring HELO==FCRDNS {in incomming} on the other hand will make the job of best practice senders more difficult, as people following your advice will reject the better senders. and only accept mail from those following this foolish policy and ratware{which already does}

At 10:03 09/03/2010 Tuesday, Alex van den Bogaerdt wrote:
>>there is no such thing as "official hostname" , the closest to that would
>>be the name configured on the box itself and returned by the $HOSTNAME
>>variable or hostname command
>
>And, as the HELO/EHLO command identifies the host, this is the name which
>should be used.

yes the hostname {which may be one of many A records pointed at the host}
not the FQRDNS {the specific hostname(s) used to identify the organization that is in control of the ip, verified {to defeat forgery} via doing a IP>PTR>A>IP verification chain
as the Organisation owning the A zone is frequently not the organisation administering the PTR thus verification is neccisary

>>as long as it has an A record it is fine in a HELO, using any hostname* is
>>legit vis a vis the RFC {as quoted above [and originally by you]}
>
>That text is to explain the difference between A and CNAME. It does not tell
>you that you can use any existing hostname or worse.

actually it does, it even specifically says that the HELO name pointing at ANY ip {not even the one used by the connecting client} is OK
we in the receiving community decided that we would strengthen this lax policy through SPF and CSV {to authenticate the HELO and limit the ips it would be accepted from}
HELOs without any stated policy {spf or csv} CAN be verified 'by does this point at the connecting ip' by reciever policy, but it would result in MANY false positives {all of face book for example}

verifying the helo further by tieing it to the same forward zone as the PTR is many receivers CHOICE {it definitely separates out the well setup from the rest} {and thus the ones likely to react to complaints if their users spam}

but mistakenly trying to force a policy requiring HELO to equal FCRDNS is NOT in the rfc's {whatever you may infer}
and is patently a really dumb idea
if better than RFC compliant behaviour is to be expected in HELO/EHLO then actually demand usefully better behaviour, not HELO==FCRDNS as every piece of malware/ratware already complies with this so it serves no purpouse other than to make life easier for ratware authors

>Following your line of reasoning, I would also be allowed to use your
>hostname... of course I am not.

you are {per the rfc's
you are not per my helo's stated CSV and SPF policy {one of my servers HELOs atm as bigsvr.alandoherty.net, its policy only allows this from its own ip, its ptr on the other hand has a deny spf and csv so even if ratware infested the host it could not successfully helo without parsing my exim config}

>>that is BULLSHIT!! plain and simple, its backward ass thinking and nothing to do with the rfc's
>
>Please make your point without using such language.

it would be easier if you did not continually state the ridiculous

>>>>{but the point is a hostname does not have to be the same hostname used
>>>>within the PTR,
>>>>and in these modern times SHOULD NOT BE
>>>
>>>Okay, I'm willing to agree with you here. What better information than
>>>RFC1035 do you have?
>>
>>simple experience of knowing that its programmatically impossible to
>>determine if a connection from a host in 99.99% of static ranges {ones
>>with a ptr allocated to businesses for the express intent of ensuring they
>>can run in-house mta's} originated with the MTA {good} or any random
>>desktop {BAD} if they follow the backward idea that their MTA should helo
>>with its FQRDNS name
>
>
>This is what the RFC, written in these modern times (oct 2008), has to say
>about it:
>
>"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), the client SHOULD send an address literal (see Section
>4.1.3).
>"
>
>What follows from this? A domain which does not have a reverse mapping is not a meaningful hostname and must not be used as HELO parameter.

you infer this, it is not what the document states
the document actually implys that if a client host talking [e]smtp
{and by that i do mean client as opposed to a MTA that is not allowed by any reciever to connect if it has no verifiable PTR {FCRDNS}}
has no method to determine its hostname [as it cannot lookup its PTR it not having one]{ie windows box that did not receive a dns name from AD/dhcp etc.} should helo as [its.ip.add.res] as opposed to a non qualified hostname such as mypc with no domain

some receivers choose to allow [xx.xx.xx.xx] address literals in direct to MX reception {most do not} no legit sender ever tries

>It is possible for a host to have more than one name which passes the A->PTR->same_A test.

there has never been such a test, no verification of A is necessary as the zone is under the control of the domain owner, only PTR's can and are regularly forged to imply that IP belongs to an organisations other than the real owner {thus the invention of IP>PTR>A>IP verification and the fact it is now used in all MTA's before a PTR is accepted/used/logged

> This could for instance happen on a multi homed host with different names for each interface. That does still not mean you can select any of those names.

actually you can have any number of PTRs on a single ip lookup any of hotmails sending IPs
its still pointless and dumb, but its easy to do, without needing to be multihomed

but back to your original example if a machine is multihomed {several ips, each with one unique PTR} {assuming the A's do not point at all the ips, just the one that the PTR is used for}
you cannot safely use any of them in a HELO
{both because FCRDNS should be avoided in HELO, and because you may connect out from an ip that doesn't match your HELO}
you should HELO as a hostname {within the same domain as the PTRs} that points to all the IPs, and thus can be A>IP verified and SPF / CSV verified also}

>The HELO parameter identifies the host. It does not identify the interface used, nor does it identify the organization as some seem to think.

the hostname contains a parent domain, thus it does identify an organization that has responsibility for the mail/abuse it sends.

> There's nothing wrong with using, say, www.openspf.org (provided that this is a name which resolves to an address which resolves back to the same name).

this is entirely untrue, woolly thinking and unsafe practice to promote

>>>Are you the same Alan that wrote:
>>>
>>>"www.microsoft.com is an alias thus has no A or MX and should be refused by all mailservers
>>>>>{crazily it points at microsoft.com and thus some dodgy libraries/mta's that follow aliases will allow user@www.micr.. and use the mx's from and spf from microsoft.com which I doubt they really wanted}"
>>
>>yes, its an alias thus SHOULD BE REFUSED as a HELO name which is what we are discussing
>
>If you were discussing HELO parameters, why did you choose an example of user@www.microsoft ?

as it was one of the domains listed by the original poster where a subdomain {guessable to exist} had a cname record so could be used to illustrate the point of where a HELO would be invalid {without looking for SPF or CSV}

he was asking about forgery of sub-domains where no SPF record is present, thus i was illustrating from his example list places where forgery of user@www and helo as www. would be valid/invalid and intended/unintended

ie www.openspf valid intended in both helo/user@ {probably unintended in user@}
www.microsoft invalid{as HELO}/unintended for both but passes SPF checks for both {thus DNS admin needs to brush up on Cnames and their unintended side effects}

>And what is dodgy about following aliases when trying to resolve mailbox domains?

nothing, and in my last followup {cut by you} i made this clear as you were choosing to read meaning into my less exacting original statement {requoted above} that was not there
{according to the RFCs} except that the owner of this domain did not intend it to be done, thus they didn't think about the implications of using a cname fully

my original restating of above in less re-interpretable language {for those insistent of reading unintended meanings into everything}

--------------------
yes, its an alias thus SHOULD BE REFUSED as a HELO name which is what we are discussing
and as it aliases to a domain with both A and MX records it would still be valid for user@www.microsoft {which their MX's do NOT accept thus is not what they intended}
and as some dodgy implementations of SPF libraries do follow cname-chains to txt/spf records and would therefore mistakenly allow in HELO and in envelope-from {which as i have mentioned was NOT their intent}
and as their microsoft.com spf ends in ~all would allow both unintended uses from everywhere
-------------------------------




>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/
>Powered by Listbox: http://www.listbox.com



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com
Re: Falling back to parent domains... [ In reply to ]
----- Original Message -----
From: "alan" <spfdiscuss@alandoherty.net>
To: <spf-help@v2.listbox.com>; <spf-help@v2.listbox.com>
Sent: Tuesday, March 09, 2010 1:50 PM
Subject: Re: [spf-help] Falling back to parent domains...


> Last post DECLARING THREAD DEAD
> there is no point arguing with the willful ignorant, they will drag you
> down to their level and beat you with experience.

Have it your way.

Can I expect to find your name in the succesor of rfc5321?



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com