SPF Record Issue

[Roman Gelfand]

I have added the spf text record, below. The first and second subnets
are being checked. However, when sending email from 3rd and 4th
subnet, spf check fails. Does this mean only 2 subnets could be
specified. If so, what to when there is more subnets?

v=spf1 ip4:xx.xxx.0.0/14 ip4:24.yy.yyy.yyy.80/29 ip4:zz.zz.zz.24/29
ip4:uuu.uu.uuu.0/29 -all

Thanks in advance

[Scott Kitterman]

On Monday, September 09, 2013 11:52:19 Roman Gelfand wrote:
> I have added the spf text record, below. The first and second subnets
> are being checked. However, when sending email from 3rd and 4th
> subnet, spf check fails. Does this mean only 2 subnets could be
> specified. If so, what to when there is more subnets?
>
> v=spf1 ip4:xx.xxx.0.0/14 ip4:24.yy.yyy.yyy.80/29 ip4:zz.zz.zz.24/29
> ip4:uuu.uu.uuu.0/29 -all

It's very difficult to tell if you don't give us the domain in question so we
can look up the record directly. What you've posted looks fine.

Scott K

[Stuart Gathman]

On 09/09/2013 11:52 AM, Roman Gelfand wrote:
> I have added the spf text record, below. The first and second subnets
> are being checked. However, when sending email from 3rd and 4th
> subnet, spf check fails. Does this mean only 2 subnets could be
> specified. If so, what to when there is more subnets?
>
> v=spf1 ip4:xx.xxx.0.0/14 ip4:24.yy.yyy.yyy.80/29 ip4:zz.zz.zz.24/29
The second ip4 has 5 octets. That MUST get PermErr for any IP (but
whatever you are checking with may not be fully conformant.) On the
other hand, that may just be a typo when obfuscating the record. You
are publishing the record in DNS, for crying out loud, so just give us
the actual record. Also, people sometimes have trouble with TXT records
on their DNS host, so you should load the record into a
test.yourdomain.com domain on the same DNS server you will be using for
production. Then we can check that it is actually served correctly.
> ip4:uuu.uu.uuu.0/29 -all

[Roman Gelfand]

Yep, you are right. The domain name is unbeatablesale.com

On Mon, Sep 9, 2013 at 12:01 PM, Stuart Gathman <***@gathman.org> wrote:
> On 09/09/2013 11:52 AM, Roman Gelfand wrote:
>>
>> I have added the spf text record, below. The first and second subnets
>> are being checked. However, when sending email from 3rd and 4th
>> subnet, spf check fails. Does this mean only 2 subnets could be
>> specified. If so, what to when there is more subnets?
>>
>> v=spf1 ip4:xx.xxx.0.0/14 ip4:24.yy.yyy.yyy.80/29 ip4:zz.zz.zz.24/29
>
> The second ip4 has 5 octets. That MUST get PermErr for any IP (but
> whatever you are checking with may not be fully conformant.) On the other
> hand, that may just be a typo when obfuscating the record. You are
> publishing the record in DNS, for crying out loud, so just give us the
> actual record. Also, people sometimes have trouble with TXT records on
> their DNS host, so you should load the record into a test.yourdomain.com
> domain on the same DNS server you will be using for production. Then we can
> check that it is actually served correctly.
>>
>> ip4:uuu.uu.uuu.0/29 -all
>
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
> Modify Your Subscription:
> https://www.listbox.com/member/?&
> Unsubscribe Now:
> https://www.listbox.com/unsubscribe/?&&post_id=20130909120211:2B4082F0-1969-11E3-B924-E2C56875045B
>
> Powered by Listbox: http://www.listbox.com

[alan]

At 17:10 09/09/2013 Monday, Roman Gelfand wrote:
>Yep, you are right. The domain name is unbeatablesale.com

ok
unbeatablesale.com text = "v=spf1 ip4:98.136.0.0/14 ip4:24.187.208.80/29 ip4:24.38.11.24/29 ip4:108.58.151.0/29 -all"

that is
98.136.0.0 - 98.136.196.255 (wow)
24.187.208.80 - 24.187.208.87
24.38.11.24 - 24.38.11.31
108.58.151.0 - 108.58.151.7

now what ip is appearing to fail?

as no there is no limit on the number of subnets other than the limits of how many text characters in a typical dns txt reply
(you are way short of running into this limit thus not a concern)

could you include the pass/fail output of whatever tester was in use?

as it could be reporting not the failure of the spf check on the sender
***@unbeatablesale.com
but an spf fail on the domain in the sending systems helo-id (which is a separate test entirely)




>On Mon, Sep 9, 2013 at 12:01 PM, Stuart Gathman <***@gathman.org> wrote:
>> On 09/09/2013 11:52 AM, Roman Gelfand wrote:
>>>
>>> I have added the spf text record, below. The first and second subnets
>>> are being checked. However, when sending email from 3rd and 4th
>>> subnet, spf check fails. Does this mean only 2 subnets could be
>>> specified. If so, what to when there is more subnets?
>>>
>>> v=spf1 ip4:xx.xxx.0.0/14 ip4:24.yy.yyy.yyy.80/29 ip4:zz.zz.zz.24/29
>>
>> The second ip4 has 5 octets. That MUST get PermErr for any IP (but
>> whatever you are checking with may not be fully conformant.) On the other
>> hand, that may just be a typo when obfuscating the record. You are
>> publishing the record in DNS, for crying out loud, so just give us the
>> actual record. Also, people sometimes have trouble with TXT records on
>> their DNS host, so you should load the record into a test.yourdomain.com
>> domain on the same DNS server you will be using for production. Then we can
>> check that it is actually served correctly.
>>>
>>> ip4:uuu.uu.uuu.0/29 -all
>>
>>
>>
>>
>> -------------------------------------------
>> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>> Modify Your Subscription: http://www.listbox.com/member/
>> [http://www.listbox.com/member/]
>>
>> Archives: https://www.listbox.com/member/archive/735/=now
>> RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
>> Modify Your Subscription:
>> https://www.listbox.com/member/?&
>> Unsubscribe Now:
>> https://www.listbox.com/unsubscribe/?&&post_id=20130909120211:2B4082F0-1969-11E3-B924-E2C56875045B
>>
>> Powered by Listbox: http://www.listbox.com
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/735/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909121059:682580A2-196A-11E3-AEC7-E0792EE61468
>Powered by Listbox: http://www.listbox.com

[Roman Gelfand]

The ip it failed on is 24.38.11.30.

In fact, the helo host name doesn't resolve to this address. Based on
what you mentioned in you previous post, I suppose this is the issue.

Received: from pmx1.unbeatablesale.biz (mmxr02.unbeatablesale.biz.
[24.38.119.30])
by mx.google.com with ESMTP id z10si422023qas.154.1969.12.31.16.00.00;
Mon, 09 Sep 2013 06:05:42 -0700 (PDT)
Received-SPF: fail (google.com: domain of ***@unbeatablesale.com does
not designate 24.38.119.30 as permitted sender)
client-ip=24.38.119.30;
Authentication-Results: mx.google.com;
spf=hardfail (google.com: domain of ***@unbeatablesale.com
does not designate 24.38.119.30 as permitted sender)
smtp.mail=***@unbeatablesale.com


On Mon, Sep 9, 2013 at 12:48 PM, alan <***@alandoherty.net> wrote:
> At 17:10 09/09/2013 Monday, Roman Gelfand wrote:
>>Yep, you are right. The domain name is unbeatablesale.com
>
> ok
> unbeatablesale.com text = "v=spf1 ip4:98.136.0.0/14 ip4:24.187.208.80/29 ip4:24.38.11.24/29 ip4:108.58.151.0/29 -all"
>
> that is
> 98.136.0.0 - 98.136.196.255 (wow)
> 24.187.208.80 - 24.187.208.87
> 24.38.11.24 - 24.38.11.31
> 108.58.151.0 - 108.58.151.7
>
> now what ip is appearing to fail?
>
> as no there is no limit on the number of subnets other than the limits of how many text characters in a typical dns txt reply
> (you are way short of running into this limit thus not a concern)
>
> could you include the pass/fail output of whatever tester was in use?
>
> as it could be reporting not the failure of the spf check on the sender
> ***@unbeatablesale.com
> but an spf fail on the domain in the sending systems helo-id (which is a separate test entirely)
>
>
>
>
>>On Mon, Sep 9, 2013 at 12:01 PM, Stuart Gathman <***@gathman.org> wrote:
>>> On 09/09/2013 11:52 AM, Roman Gelfand wrote:
>>>>
>>>> I have added the spf text record, below. The first and second subnets
>>>> are being checked. However, when sending email from 3rd and 4th
>>>> subnet, spf check fails. Does this mean only 2 subnets could be
>>>> specified. If so, what to when there is more subnets?
>>>>
>>>> v=spf1 ip4:xx.xxx.0.0/14 ip4:24.yy.yyy.yyy.80/29 ip4:zz.zz.zz.24/29
>>>
>>> The second ip4 has 5 octets. That MUST get PermErr for any IP (but
>>> whatever you are checking with may not be fully conformant.) On the other
>>> hand, that may just be a typo when obfuscating the record. You are
>>> publishing the record in DNS, for crying out loud, so just give us the
>>> actual record. Also, people sometimes have trouble with TXT records on
>>> their DNS host, so you should load the record into a test.yourdomain.com
>>> domain on the same DNS server you will be using for production. Then we can
>>> check that it is actually served correctly.
>>>>
>>>> ip4:uuu.uu.uuu.0/29 -all
>>>
>>>
>>>
>>>
>>> -------------------------------------------
>>> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>> Modify Your Subscription: http://www.listbox.com/member/
>>> [http://www.listbox.com/member/]
>>>
>>> Archives: https://www.listbox.com/member/archive/735/=now
>>> RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
>>> Modify Your Subscription:
>>> https://www.listbox.com/member/?&
>>> Unsubscribe Now:
>>> https://www.listbox.com/unsubscribe/?&&post_id=20130909120211:2B4082F0-1969-11E3-B924-E2C56875045B
>>>
>>> Powered by Listbox: http://www.listbox.com
>>
>>
>>-------------------------------------------
>>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>
>>Archives: https://www.listbox.com/member/archive/735/=now
>>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
>>Modify Your Subscription: https://www.listbox.com/member/?&
>>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909121059:682580A2-196A-11E3-AEC7-E0792EE61468
>>Powered by Listbox: http://www.listbox.com
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
> Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
> Modify Your Subscription: https://www.listbox.com/member/?&
> Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909124817:9E65463E-196F-11E3-9A41-BF4B57BB7C94
> Powered by Listbox: http://www.listbox.com

[alan]

At 18:00 09/09/2013 Monday, Roman Gelfand wrote:
>The ip it failed on is 24.38.11.30.
>
>In fact, the helo host name doesn't resolve to this address. Based on
>what you mentioned in you previous post, I suppose this is the issue.

shouldn't cause the fail that it did though (but could be a bug in googles reporting)

as the helo pmx1.unbeatablesale.biz has no spf record to fail
but should have "v=spf1 ip4:24.38.11.30 -all"
or "v=spf1 a -all" if you also fix the a record ;)



>Received: from pmx1.unbeatablesale.biz (mmxr02.unbeatablesale.biz.
>[24.38.119.30])
> by mx.google.com with ESMTP id z10si422023qas.154.1969.12.31.16.00.00;
> Mon, 09 Sep 2013 06:05:42 -0700 (PDT)
>Received-SPF: fail (google.com: domain of ***@unbeatablesale.com does
>not designate 24.38.119.30 as permitted sender)
>client-ip=24.38.119.30;
>Authentication-Results: mx.google.com;
> spf=hardfail (google.com: domain of ***@unbeatablesale.com
>does not designate 24.38.119.30 as permitted sender)
>smtp.mail=***@unbeatablesale.com

those results do suggest that it was an envelope sender fail
(it could be one cached from an earlier version of your spf)

but unlikely as it says this spf has been unchanged since 2013 08 29 02
and it has only a 8 hour cache
unless it has been changed since and the old soa is making google ignore the updates

either way diagnostic fix is to update the A for
pmx1.unbeatablesale.biz to point at 24.38.119.30 (and whatever other ips it has)
add a txt for
pmx1.unbeatablesale.biz "v=spf1 ip4:24.38.11.30 -all"
update the soa for unbeatablesale.biz

try again

then update the soa for unbeatablesale.com

then try again in 8 hours

if it works it was likely one or the other ;)




>On Mon, Sep 9, 2013 at 12:48 PM, alan <***@alandoherty.net> wrote:
>> At 17:10 09/09/2013 Monday, Roman Gelfand wrote:
>>>Yep, you are right. The domain name is unbeatablesale.com
>>
>> ok
>> unbeatablesale.com text = "v=spf1 ip4:98.136.0.0/14 ip4:24.187.208.80/29 ip4:24.38.11.24/29 ip4:108.58.151.0/29 -all"
>>
>> that is
>> 98.136.0.0 - 98.136.196.255 (wow)
>> 24.187.208.80 - 24.187.208.87
>> 24.38.11.24 - 24.38.11.31
>> 108.58.151.0 - 108.58.151.7
>>
>> now what ip is appearing to fail?
>>
>> as no there is no limit on the number of subnets other than the limits of how many text characters in a typical dns txt reply
>> (you are way short of running into this limit thus not a concern)
>>
>> could you include the pass/fail output of whatever tester was in use?
>>
>> as it could be reporting not the failure of the spf check on the sender
>> ***@unbeatablesale.com
>> but an spf fail on the domain in the sending systems helo-id (which is a separate test entirely)
>>
>>
>>
>>
>>>On Mon, Sep 9, 2013 at 12:01 PM, Stuart Gathman <***@gathman.org> wrote:
>>>> On 09/09/2013 11:52 AM, Roman Gelfand wrote:
>>>>>
>>>>> I have added the spf text record, below. The first and second subnets
>>>>> are being checked. However, when sending email from 3rd and 4th
>>>>> subnet, spf check fails. Does this mean only 2 subnets could be
>>>>> specified. If so, what to when there is more subnets?
>>>>>
>>>>> v=spf1 ip4:xx.xxx.0.0/14 ip4:24.yy.yyy.yyy.80/29 ip4:zz.zz.zz.24/29
>>>>
>>>> The second ip4 has 5 octets. That MUST get PermErr for any IP (but
>>>> whatever you are checking with may not be fully conformant.) On the other
>>>> hand, that may just be a typo when obfuscating the record. You are
>>>> publishing the record in DNS, for crying out loud, so just give us the
>>>> actual record. Also, people sometimes have trouble with TXT records on
>>>> their DNS host, so you should load the record into a test.yourdomain.com
>>>> domain on the same DNS server you will be using for production. Then we can
>>>> check that it is actually served correctly.
>>>>>
>>>>> ip4:uuu.uu.uuu.0/29 -all
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------
>>>> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>>> Modify Your Subscription: http://www.listbox.com/member/
>>>> [http://www.listbox.com/member/]
>>>>
>>>> Archives: https://www.listbox.com/member/archive/735/=now
>>>> RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
>>>> Modify Your Subscription:
>>>> https://www.listbox.com/member/?&
>>>> Unsubscribe Now:
>>>> https://www.listbox.com/unsubscribe/?&&post_id=20130909120211:2B4082F0-1969-11E3-B924-E2C56875045B
>>>>
>>>> Powered by Listbox: http://www.listbox.com
>>>
>>>
>>>-------------------------------------------
>>>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>>
>>>Archives: https://www.listbox.com/member/archive/735/=now
>>>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
>>>Modify Your Subscription: https://www.listbox.com/member/?&
>>>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909121059:682580A2-196A-11E3-AEC7-E0792EE61468
>>>Powered by Listbox: http://www.listbox.com
>>
>>
>>
>> -------------------------------------------
>> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>> Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>
>> Archives: https://www.listbox.com/member/archive/735/=now
>> RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
>> Modify Your Subscription: https://www.listbox.com/member/?&
>> Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909124817:9E65463E-196F-11E3-9A41-BF4B57BB7C94
>> Powered by Listbox: http://www.listbox.com
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/735/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909130024:4E5D6DC2-1971-11E3-932D-84D22AAAEFF8
>Powered by Listbox: http://www.listbox.com

[Philip Gladstone]

Note that the SPF record would allow 24.38.11.30, but the failing IP is
24.38.119.30

Philip


On 9/9/13 1:00 PM, Roman Gelfand wrote:
> The ip it failed on is 24.38.11.30.
>
> In fact, the helo host name doesn't resolve to this address. Based on
> what you mentioned in you previous post, I suppose this is the issue.
>
> Received: from pmx1.unbeatablesale.biz (mmxr02.unbeatablesale.biz.
> [24.38.119.30])
> by mx.google.com with ESMTP id z10si422023qas.154.1969.12.31.16.00.00;
> Mon, 09 Sep 2013 06:05:42 -0700 (PDT)
> Received-SPF: fail (google.com: domain of ***@unbeatablesale.com does
> not designate 24.38.119.30 as permitted sender)
> client-ip=24.38.119.30;
> Authentication-Results: mx.google.com;
> spf=hardfail (google.com: domain of ***@unbeatablesale.com
> does not designate 24.38.119.30 as permitted sender)
> smtp.mail=***@unbeatablesale.com
>
>
> On Mon, Sep 9, 2013 at 12:48 PM, alan <***@alandoherty.net> wrote:
>> At 17:10 09/09/2013 Monday, Roman Gelfand wrote:
>>> Yep, you are right. The domain name is unbeatablesale.com
>> ok
>> unbeatablesale.com text = "v=spf1 ip4:98.136.0.0/14 ip4:24.187.208.80/29 ip4:24.38.11.24/29 ip4:108.58.151.0/29 -all"
>>
>> that is
>> 98.136.0.0 - 98.136.196.255 (wow)
>> 24.187.208.80 - 24.187.208.87
>> 24.38.11.24 - 24.38.11.31
>> 108.58.151.0 - 108.58.151.7
>>
>> now what ip is appearing to fail?
>>
>> as no there is no limit on the number of subnets other than the limits of how many text characters in a typical dns txt reply
>> (you are way short of running into this limit thus not a concern)
>>
>> could you include the pass/fail output of whatever tester was in use?
>>
>> as it could be reporting not the failure of the spf check on the sender
>> ***@unbeatablesale.com
>> but an spf fail on the domain in the sending systems helo-id (which is a separate test entirely)
>>
>>
>>
>>
>>> On Mon, Sep 9, 2013 at 12:01 PM, Stuart Gathman <***@gathman.org> wrote:
>>>> On 09/09/2013 11:52 AM, Roman Gelfand wrote:
>>>>> I have added the spf text record, below. The first and second subnets
>>>>> are being checked. However, when sending email from 3rd and 4th
>>>>> subnet, spf check fails. Does this mean only 2 subnets could be
>>>>> specified. If so, what to when there is more subnets?
>>>>>
>>>>> v=spf1 ip4:xx.xxx.0.0/14 ip4:24.yy.yyy.yyy.80/29 ip4:zz.zz.zz.24/29
>>>> The second ip4 has 5 octets. That MUST get PermErr for any IP (but
>>>> whatever you are checking with may not be fully conformant.) On the other
>>>> hand, that may just be a typo when obfuscating the record. You are
>>>> publishing the record in DNS, for crying out loud, so just give us the
>>>> actual record. Also, people sometimes have trouble with TXT records on
>>>> their DNS host, so you should load the record into a test.yourdomain.com
>>>> domain on the same DNS server you will be using for production. Then we can
>>>> check that it is actually served correctly.
>>>>> ip4:uuu.uu.uuu.0/29 -all
>>>>
>>>>
>>>>
>>>> -------------------------------------------
>>>> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>>> Modify Your Subscription: http://www.listbox.com/member/
>>>> [http://www.listbox.com/member/]
>>>>
>>>> Archives: https://www.listbox.com/member/archive/735/=now
>>>> RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
>>>> Modify Your Subscription:
>>>> https://www.listbox.com/member/?&
>>>> Unsubscribe Now:
>>>> https://www.listbox.com/unsubscribe/?&&post_id=20130909120211:2B4082F0-1969-11E3-B924-E2C56875045B
>>>>
>>>> Powered by Listbox: http://www.listbox.com
>>>
>>> -------------------------------------------
>>> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>> Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>>
>>> Archives: https://www.listbox.com/member/archive/735/=now
>>> RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
>>> Modify Your Subscription: https://www.listbox.com/member/?&
>>> Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909121059:682580A2-196A-11E3-AEC7-E0792EE61468
>>> Powered by Listbox: http://www.listbox.com
>>
>>
>> -------------------------------------------
>> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>> Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>
>> Archives: https://www.listbox.com/member/archive/735/=now
>> RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
>> Modify Your Subscription: https://www.listbox.com/member/?&
>> Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909124817:9E65463E-196F-11E3-9A41-BF4B57BB7C94
>> Powered by Listbox: http://www.listbox.com
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
> Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/835710-69e7d341
> Modify Your Subscription: https://www.listbox.com/member/?&
> Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909130024:4E5D6DC2-1971-11E3-932D-84D22AAAEFF8
> Powered by Listbox: http://www.listbox.com
>

[alan]

At 18:31 09/09/2013 Monday, Philip Gladstone wrote:
>Note that the SPF record would allow 24.38.11.30, but the failing IP is 24.38.119.30

damn my eyes Philip yer a star
(and i even cut pasted that in portions of my response without seeing it)

ignore all i said earlier

note philips response

then after adding the subnet for this ip

fix/update the A for
pmx1.unbeatablesale.biz to point at 24.38.119.30 (and whatever other ips it has)
add a txt for
pmx1.unbeatablesale.biz "v=spf1 ip4:24.38.119.30 -all"

also add an spf to every other domain used in helo

and add a "v=spf1 -all" to all domains not used in helo or sender address's
to be thorough in forgery blocking


remember SPF is about forgery blocking, people only think it makes your non-forged mails look less spammy because you seem to be trying to block forgeries

(i say this as im personally thinking of amending the positive score for a spf pass on my own hosts so that it only applies if the helo(if in same domain) had an spf and www(if it exists) has an spf also)

just to reward those actually using spf for anti-forgery not for deliverability
(that said its just an idea thus far)



>Philip
>
>
>On 9/9/13 1:00 PM, Roman Gelfand wrote:
>>The ip it failed on is 24.38.11.30.
>>
>>In fact, the helo host name doesn't resolve to this address. Based on
>>what you mentioned in you previous post, I suppose this is the issue.
>>
>>Received: from pmx1.unbeatablesale.biz (mmxr02.unbeatablesale.biz.
>>[24.38.119.30])
>> by mx.google.com with ESMTP id z10si422023qas.154.1969.12.31.16.00.00;
>> Mon, 09 Sep 2013 06:05:42 -0700 (PDT)
>>Received-SPF: fail (google.com: domain of ***@unbeatablesale.com does
>>not designate 24.38.119.30 as permitted sender)
>>client-ip=24.38.119.30;
>>Authentication-Results: mx.google.com;
>> spf=hardfail (google.com: domain of ***@unbeatablesale.com
>>does not designate 24.38.119.30 as permitted sender)
>>smtp.mail=***@unbeatablesale.com
>>
>>
>>On Mon, Sep 9, 2013 at 12:48 PM, alan <***@alandoherty.net> wrote:
>>>At 17:10 09/09/2013 Monday, Roman Gelfand wrote:
>>>>Yep, you are right. The domain name is unbeatablesale.com
>>>ok
>>>unbeatablesale.com text = "v=spf1 ip4:98.136.0.0/14 ip4:24.187.208.80/29 ip4:24.38.11.24/29 ip4:108.58.151.0/29 -all"
>>>
>>>that is
>>>98.136.0.0 - 98.136.196.255 (wow)
>>>24.187.208.80 - 24.187.208.87
>>>24.38.11.24 - 24.38.11.31
>>>108.58.151.0 - 108.58.151.7
>>>
>>>now what ip is appearing to fail?
>>>
>>>as no there is no limit on the number of subnets other than the limits of how many text characters in a typical dns txt reply
>>>(you are way short of running into this limit thus not a concern)
>>>
>>>could you include the pass/fail output of whatever tester was in use?
>>>
>>>as it could be reporting not the failure of the spf check on the sender
>>>***@unbeatablesale.com
>>>but an spf fail on the domain in the sending systems helo-id (which is a separate test entirely)
>>>
>>>
>>>
>>>
>>>>On Mon, Sep 9, 2013 at 12:01 PM, Stuart Gathman <***@gathman.org> wrote:
>>>>>On 09/09/2013 11:52 AM, Roman Gelfand wrote:
>>>>>>I have added the spf text record, below. The first and second subnets
>>>>>>are being checked. However, when sending email from 3rd and 4th
>>>>>>subnet, spf check fails. Does this mean only 2 subnets could be
>>>>>>specified. If so, what to when there is more subnets?
>>>>>>
>>>>>>v=spf1 ip4:xx.xxx.0.0/14 ip4:24.yy.yyy.yyy.80/29 ip4:zz.zz.zz.24/29
>>>>> The second ip4 has 5 octets. That MUST get PermErr for any IP (but
>>>>>whatever you are checking with may not be fully conformant.) On the other
>>>>>hand, that may just be a typo when obfuscating the record. You are
>>>>>publishing the record in DNS, for crying out loud, so just give us the
>>>>>actual record. Also, people sometimes have trouble with TXT records on
>>>>>their DNS host, so you should load the record into a test.yourdomain.com
>>>>>domain on the same DNS server you will be using for production. Then we can
>>>>>check that it is actually served correctly.
>>>>>>ip4:uuu.uu.uuu.0/29 -all
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------
>>>>>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>>>>Modify Your Subscription: http://www.listbox.com/member/
>>>>>[http://www.listbox.com/member/]
>>>>>
>>>>>Archives: https://www.listbox.com/member/archive/735/=now
>>>>>RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
>>>>>Modify Your Subscription:
>>>>>https://www.listbox.com/member/?&
>>>>>Unsubscribe Now:
>>>>>https://www.listbox.com/unsubscribe/?&&post_id=20130909120211:2B4082F0-1969-11E3-B924-E2C56875045B
>>>>>
>>>>>Powered by Listbox: http://www.listbox.com
>>>>
>>>>-------------------------------------------
>>>>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>>>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>>>
>>>>Archives: https://www.listbox.com/member/archive/735/=now
>>>>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
>>>>Modify Your Subscription: https://www.listbox.com/member/?&
>>>>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909121059:682580A2-196A-11E3-AEC7-E0792EE61468
>>>>Powered by Listbox: http://www.listbox.com
>>>
>>>
>>>-------------------------------------------
>>>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>>
>>>Archives: https://www.listbox.com/member/archive/735/=now
>>>RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
>>>Modify Your Subscription: https://www.listbox.com/member/?&
>>>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909124817:9E65463E-196F-11E3-9A41-BF4B57BB7C94
>>>Powered by Listbox: http://www.listbox.com
>>
>>-------------------------------------------
>>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>
>>Archives: https://www.listbox.com/member/archive/735/=now
>>RSS Feed: https://www.listbox.com/member/archive/rss/735/835710-69e7d341
>>Modify Your Subscription: https://www.listbox.com/member/?&
>>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909130024:4E5D6DC2-1971-11E3-932D-84D22AAAEFF8
>>Powered by Listbox: http://www.listbox.com
>
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/735/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909133207:BA44D594-1975-11E3-B873-E046EBFE4541
>Powered by Listbox: http://www.listbox.com

[Roman Gelfand]

yes, but how do you explain this...

Received: from pmx1.unbeatablesale.biz
(ool-18bbd052.static.optonline.net. [24.187.208.82])
by mx.google.com with ESMTP id m4si644491qae.157.1969.12.31.16.00.00;
Mon, 09 Sep 2013 07:55:05 -0700 (PDT)
Received-SPF: pass (google.com: domain of ***@unbeatablesale.com
designates 24.187.208.82 as permitted sender) client-ip=24.187.208.82;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of ***@unbeatablesale.com
designates 24.187.208.82 as permitted sender)
smtp.mail=***@unbeatablesale.com

On Mon, Sep 9, 2013 at 2:05 PM, alan <***@alandoherty.net> wrote:
> At 18:31 09/09/2013 Monday, Philip Gladstone wrote:
>>Note that the SPF record would allow 24.38.11.30, but the failing IP is 24.38.119.30
>
> damn my eyes Philip yer a star
> (and i even cut pasted that in portions of my response without seeing it)
>
> ignore all i said earlier
>
> note philips response
>
> then after adding the subnet for this ip
>
> fix/update the A for
> pmx1.unbeatablesale.biz to point at 24.38.119.30 (and whatever other ips it has)
> add a txt for
> pmx1.unbeatablesale.biz "v=spf1 ip4:24.38.119.30 -all"
>
> also add an spf to every other domain used in helo
>
> and add a "v=spf1 -all" to all domains not used in helo or sender address's
> to be thorough in forgery blocking
>
>
> remember SPF is about forgery blocking, people only think it makes your non-forged mails look less spammy because you seem to be trying to block forgeries
>
> (i say this as im personally thinking of amending the positive score for a spf pass on my own hosts so that it only applies if the helo(if in same domain) had an spf and www(if it exists) has an spf also)
>
> just to reward those actually using spf for anti-forgery not for deliverability
> (that said its just an idea thus far)
>
>
>
>>Philip
>>
>>
>>On 9/9/13 1:00 PM, Roman Gelfand wrote:
>>>The ip it failed on is 24.38.11.30.
>>>
>>>In fact, the helo host name doesn't resolve to this address. Based on
>>>what you mentioned in you previous post, I suppose this is the issue.
>>>
>>>Received: from pmx1.unbeatablesale.biz (mmxr02.unbeatablesale.biz.
>>>[24.38.119.30])
>>> by mx.google.com with ESMTP id z10si422023qas.154.1969.12.31.16.00.00;
>>> Mon, 09 Sep 2013 06:05:42 -0700 (PDT)
>>>Received-SPF: fail (google.com: domain of ***@unbeatablesale.com does
>>>not designate 24.38.119.30 as permitted sender)
>>>client-ip=24.38.119.30;
>>>Authentication-Results: mx.google.com;
>>> spf=hardfail (google.com: domain of ***@unbeatablesale.com
>>>does not designate 24.38.119.30 as permitted sender)
>>>smtp.mail=***@unbeatablesale.com
>>>
>>>
>>>On Mon, Sep 9, 2013 at 12:48 PM, alan <***@alandoherty.net> wrote:
>>>>At 17:10 09/09/2013 Monday, Roman Gelfand wrote:
>>>>>Yep, you are right. The domain name is unbeatablesale.com
>>>>ok
>>>>unbeatablesale.com text = "v=spf1 ip4:98.136.0.0/14 ip4:24.187.208.80/29 ip4:24.38.11.24/29 ip4:108.58.151.0/29 -all"
>>>>
>>>>that is
>>>>98.136.0.0 - 98.136.196.255 (wow)
>>>>24.187.208.80 - 24.187.208.87
>>>>24.38.11.24 - 24.38.11.31
>>>>108.58.151.0 - 108.58.151.7
>>>>
>>>>now what ip is appearing to fail?
>>>>
>>>>as no there is no limit on the number of subnets other than the limits of how many text characters in a typical dns txt reply
>>>>(you are way short of running into this limit thus not a concern)
>>>>
>>>>could you include the pass/fail output of whatever tester was in use?
>>>>
>>>>as it could be reporting not the failure of the spf check on the sender
>>>>***@unbeatablesale.com
>>>>but an spf fail on the domain in the sending systems helo-id (which is a separate test entirely)
>>>>
>>>>
>>>>
>>>>
>>>>>On Mon, Sep 9, 2013 at 12:01 PM, Stuart Gathman <***@gathman.org> wrote:
>>>>>>On 09/09/2013 11:52 AM, Roman Gelfand wrote:
>>>>>>>I have added the spf text record, below. The first and second subnets
>>>>>>>are being checked. However, when sending email from 3rd and 4th
>>>>>>>subnet, spf check fails. Does this mean only 2 subnets could be
>>>>>>>specified. If so, what to when there is more subnets?
>>>>>>>
>>>>>>>v=spf1 ip4:xx.xxx.0.0/14 ip4:24.yy.yyy.yyy.80/29 ip4:zz.zz.zz.24/29
>>>>>> The second ip4 has 5 octets. That MUST get PermErr for any IP (but
>>>>>>whatever you are checking with may not be fully conformant.) On the other
>>>>>>hand, that may just be a typo when obfuscating the record. You are
>>>>>>publishing the record in DNS, for crying out loud, so just give us the
>>>>>>actual record. Also, people sometimes have trouble with TXT records on
>>>>>>their DNS host, so you should load the record into a test.yourdomain.com
>>>>>>domain on the same DNS server you will be using for production. Then we can
>>>>>>check that it is actually served correctly.
>>>>>>>ip4:uuu.uu.uuu.0/29 -all
>>>>>>
>>>>>>
>>>>>>
>>>>>>-------------------------------------------
>>>>>>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>>>>>Modify Your Subscription: http://www.listbox.com/member/
>>>>>>[http://www.listbox.com/member/]
>>>>>>
>>>>>>Archives: https://www.listbox.com/member/archive/735/=now
>>>>>>RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
>>>>>>Modify Your Subscription:
>>>>>>https://www.listbox.com/member/?&
>>>>>>Unsubscribe Now:
>>>>>>https://www.listbox.com/unsubscribe/?&&post_id=20130909120211:2B4082F0-1969-11E3-B924-E2C56875045B
>>>>>>
>>>>>>Powered by Listbox: http://www.listbox.com
>>>>>
>>>>>-------------------------------------------
>>>>>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>>>>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>>>>
>>>>>Archives: https://www.listbox.com/member/archive/735/=now
>>>>>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
>>>>>Modify Your Subscription: https://www.listbox.com/member/?&
>>>>>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909121059:682580A2-196A-11E3-AEC7-E0792EE61468
>>>>>Powered by Listbox: http://www.listbox.com
>>>>
>>>>
>>>>-------------------------------------------
>>>>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>>>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>>>
>>>>Archives: https://www.listbox.com/member/archive/735/=now
>>>>RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
>>>>Modify Your Subscription: https://www.listbox.com/member/?&
>>>>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909124817:9E65463E-196F-11E3-9A41-BF4B57BB7C94
>>>>Powered by Listbox: http://www.listbox.com
>>>
>>>-------------------------------------------
>>>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>>
>>>Archives: https://www.listbox.com/member/archive/735/=now
>>>RSS Feed: https://www.listbox.com/member/archive/rss/735/835710-69e7d341
>>>Modify Your Subscription: https://www.listbox.com/member/?&
>>>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909130024:4E5D6DC2-1971-11E3-932D-84D22AAAEFF8
>>>Powered by Listbox: http://www.listbox.com
>>
>>
>>
>>-------------------------------------------
>>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>
>>Archives: https://www.listbox.com/member/archive/735/=now
>>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
>>Modify Your Subscription: https://www.listbox.com/member/?&
>>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909133207:BA44D594-1975-11E3-B873-E046EBFE4541
>>Powered by Listbox: http://www.listbox.com
>

[Stuart Gathman]

On 09/09/2013 02:47 PM, Roman Gelfand wrote:
> yes, but how do you explain this...
>
> Received: from pmx1.unbeatablesale.biz
> (ool-18bbd052.static.optonline.net. [24.187.208.82])
> by mx.google.com with ESMTP id m4si644491qae.157.1969.12.31.16.00.00;
> Mon, 09 Sep 2013 07:55:05 -0700 (PDT)
> Received-SPF: pass (google.com: domain of ***@unbeatablesale.com
> designates 24.187.208.82 as permitted sender) client-ip=24.187.208.82;
> Authentication-Results: mx.google.com;
> spf=pass (google.com: domain of ***@unbeatablesale.com
> designates 24.187.208.82 as permitted sender)
> smtp.mail=***@unbeatablesale.com
>
That one is sent from an IP that *is* in the list. The 24.38.119.30 has
mmxr2.unbeatablesale.com as its PTR. Your mail system sends out from
several IPs - very common with high volume email. You will need to find
out what those IPs are, authorize them, and set up a way to keep them in
sync when your mail admin guys change things around.

[Roman Gelfand]

Sorry for the bother. I just realized 24.38.11.24/29 is missing 9.
It should have been 24.38.119.24/29

On Mon, Sep 9, 2013 at 3:23 PM, Stuart Gathman <***@gathman.org> wrote:
> On 09/09/2013 02:47 PM, Roman Gelfand wrote:
>>
>> yes, but how do you explain this...
>>
>> Received: from pmx1.unbeatablesale.biz
>> (ool-18bbd052.static.optonline.net. [24.187.208.82])
>> by mx.google.com with ESMTP id
>> m4si644491qae.157.1969.12.31.16.00.00;
>> Mon, 09 Sep 2013 07:55:05 -0700 (PDT)
>> Received-SPF: pass (google.com: domain of ***@unbeatablesale.com
>> designates 24.187.208.82 as permitted sender) client-ip=24.187.208.82;
>> Authentication-Results: mx.google.com;
>> spf=pass (google.com: domain of ***@unbeatablesale.com
>> designates 24.187.208.82 as permitted sender)
>> smtp.mail=***@unbeatablesale.com
>>
> That one is sent from an IP that *is* in the list. The 24.38.119.30 has
> mmxr2.unbeatablesale.com as its PTR. Your mail system sends out from
> several IPs - very common with high volume email. You will need to find out
> what those IPs are, authorize them, and set up a way to keep them in sync
> when your mail admin guys change things around.
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
> Modify Your Subscription:
> https://www.listbox.com/member/?&
> Unsubscribe Now:
> https://www.listbox.com/unsubscribe/?&&post_id=20130909152353:5A523E6E-1985-11E3-B777-B4556EF879EB
>
> Powered by Listbox: http://www.listbox.com

[alan]

At 20:36 09/09/2013 Monday, you wrote:
>Sorry for the bother. I just realized 24.38.11.24/29 is missing 9.
>It should have been 24.38.119.24/29

thats what philip said

and as far as the helo

we have now seen that pmx1.unbeatablesale.biz
is used from 24.187.208.82 and 24.38.119.30

now if they are different machines you should consider using different helo identities for each machine
both for your own logging/tracing/diagnostics

and so they become more easily identifiable\verifiable\trustable by receivers

if they are the same machine then you should investigate and compile a list of all its ips so that you can pass the common (does helo == ip-in-A-of-helo test many receivers perform to weed out bots)

and so you can have a correct spf for this machine name
but currently you could start with

pmx1.unbeatablesale.biz v=spf1 ip4:98.136.0.0/14 ip4:24.187.208.80/29 ip4:24.38.119.24/29 ip4:108.58.151.0/29 -all

and weed it down later

btw if the /14 is as it appears to be the entire range of a VPS/cloud provider
then
A it will not matter as many receivers will have it blacklisted due to mis-use by others
B you should if running a mail sending system be able to get a set of static ips for them as all VPSs that allow mail sending do provide this service

[Roman Gelfand]

thanks for all the help. I still have a couple of questions...

1. Can you have more than 1 spf txt records for a domain?
2. What does putting host name before v=spf1 do for us? is that
somehow used in conjunction with helo? Can you have multiple host
names separated by spaces before v=spf1?
3. I am not quite sure what you mean by ...
if they are the same machine then you should investigate and compile a
list of all its ips so that you can pass the common (does helo ==
ip-in-A-of-helo test many receivers perform to weed out bots)
could you give an example.

Thanks again

On Mon, Sep 9, 2013 at 6:07 PM, alan <***@alandoherty.net> wrote:
> At 20:36 09/09/2013 Monday, you wrote:
>>Sorry for the bother. I just realized 24.38.11.24/29 is missing 9.
>>It should have been 24.38.119.24/29
>
> thats what philip said
>
> and as far as the helo
>
> we have now seen that pmx1.unbeatablesale.biz
> is used from 24.187.208.82 and 24.38.119.30
>
> now if they are different machines you should consider using different helo identities for each machine
> both for your own logging/tracing/diagnostics
>
> and so they become more easily identifiable\verifiable\trustable by receivers
>
> if they are the same machine then you should investigate and compile a list of all its ips so that you can pass the common (does helo == ip-in-A-of-helo test many receivers perform to weed out bots)
>
> and so you can have a correct spf for this machine name
> but currently you could start with
>
> pmx1.unbeatablesale.biz v=spf1 ip4:98.136.0.0/14 ip4:24.187.208.80/29 ip4:24.38.119.24/29 ip4:108.58.151.0/29 -all
>
> and weed it down later
>
> btw if the /14 is as it appears to be the entire range of a VPS/cloud provider
> then
> A it will not matter as many receivers will have it blacklisted due to mis-use by others
> B you should if running a mail sending system be able to get a set of static ips for them as all VPSs that allow mail sending do provide this service
>
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
> Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
> Modify Your Subscription: https://www.listbox.com/member/?&
> Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130909180830:5AD65ED0-199C-11E3-B4EA-D6B1BFAFFED9
> Powered by Listbox: http://www.listbox.com

[Stuart Gathman]

On 09/09/2013 07:22 PM, Roman Gelfand wrote:
> thanks for all the help. I still have a couple of questions...
>
> 1. Can you have more than 1 spf txt records for a domain?
Absolutely not.
> 2. What does putting host name before v=spf1 do for us? is that
> somehow used in conjunction with helo? Can you have multiple host
> names separated by spaces before v=spf1?
That is the syntax used by the BIND family of DNS servers used to
indicate which domain the record is for. The syntax used by your DNS
server may vary. The BIND syntax is the canonical syntax used for
discussing DNS records via email. You should learn it.

> 3. I am not quite sure what you mean by ...
> if they are the same machine then you should investigate and compile a
> list of all its ips so that you can pass the common (does helo ==
> ip-in-A-of-helo test many receivers perform to weed out bots)
> could you give an example.
Suppose the mail server uses mail1.example.com as its HELO name, and has
IPs 192.0.2.1 and 198.51.100.3 (is on two different ISPs). Then the
HELO SPF record could be

mail1.example.com IN TXT "v=spf1 ip4:192.0.2.1 ip4:198.51.100.3 -all"

Or possibly:

mail1.example.com IN TXT "v=spf1 a -all"
IN A 192.0.2.1
IN A 198.51.100.3

[alan]

At 01:04 10/09/2013 Tuesday, you wrote:
>On 09/09/2013 07:22 PM, Roman Gelfand wrote:
>>thanks for all the help. I still have a couple of questions...
>>
>>1. Can you have more than 1 spf txt records for a domain?
>Absolutely not.
>>2. What does putting host name before v=spf1 do for us? is that
>>somehow used in conjunction with helo? Can you have multiple host
>>names separated by spaces before v=spf1?
>That is the syntax used by the BIND family of DNS servers used to indicate which domain the record is for. The syntax used by your DNS server may vary. The BIND syntax is the canonical syntax used for discussing DNS records via email. You should learn it.
>
>>3. I am not quite sure what you mean by ...
>>if they are the same machine then you should investigate and compile a
>>list of all its ips so that you can pass the common (does helo ==
>>ip-in-A-of-helo test many receivers perform to weed out bots)
>>could you give an example.
>Suppose the mail server uses mail1.example.com as its HELO name, and has IPs 192.0.2.1 and 198.51.100.3 (is on two different ISPs). Then the HELO SPF record could be
>
>mail1.example.com IN TXT "v=spf1 ip4:192.0.2.1 ip4:198.51.100.3 -all"
>
>Or possibly:
>
>mail1.example.com IN TXT "v=spf1 a -all"
> IN A 192.0.2.1
> IN A 198.51.100.3


or to put it another way every hostname IS a domain (in dns terms)

thus in my case the SPF for my example domain (below)
as my real SPF records are to complex/experimental and the domains are to

but feel free to actually check the real domains alandoherty.net and alan.gothic.ie and the provider domain orionnetworks.ie that the servers are part of

but basically their are 3 mailservers
and in this example i have given one 2 ips (all ips are my own so should not annoy anyone)
(but as all are well secured by automatons probing them may result in autoblacklisting)

example.com IN A 193.120.238.106 ;my webserver/mailserver
IN MX 10 mx10.example.com ;my mailservers answering/25 helo-id and TLS cert
IN MX 20 mx20.example.com ;my other mailservers answering/25 helo-id and TLS cert
IN MX 20 mx30.example.com ;my other mailservers answering/25 helo-id and TLS cert
IN TXT "v=spf1 ip4:193.120.238.109 ip4:193.120.238.106 ip4:195.2.202.63 ip4:195.2.202.40 -all"
IN TXT "spf2.0/mfrom ip4:193.120.238.109 ip4:193.120.238.106 ip4:195.2.202.63 ip4:195.2.202.40 -all"
IN TXT "spf2.0/pra ip4:193.120.238.109 ip4:193.120.238.106 ip4:195.2.202.63 ip4:195.2.202.40 ?all"
;last 2 lines just for the broken sender-id checkers to ensure they do not block mail via mailinglists

www.example.com IN A 193.120.238.106 ;my webserver
IN MX 0 . ;explicitly states not ever legal ***@xxx
IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf

some-desktop.example.com IN A 193.120.xx.xx ;a machine
IN MX 0 . ;explicitly states not ever legal ***@xxx
IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf

support.example.com IN A 193.120.238.106 ;another website
IN MX 0 . ;explicitly states not ever legal ***@xxx
IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf

smtps.example.com IN A 193.120.238.106 ;my mailservers answering/587 helo-id and TLS cert
IN A 193.120.238.109 ;used by clients to send/relay mail outward
IN MX 0 . ;explicitly states not ever legal ***@xxx
IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf

mx10.example.com IN A 193.120.238.109 ;my mailserver incomming
IN MX 0 . ;explicitly states not ever legal ***@xxx
IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf

mx20.example.com IN A 193.120.238.106 ;my mailserver incomming
IN MX 0 . ;explicitly states not ever legal ***@xxx
IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf

mx30.example.com IN A 195.2.202.63 ;my mailserver incomming
IN A 195.2.202.40
IN MX 0 . ;explicitly states not ever legal ***@xxx
IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf

host1.example.com IN A 193.120.238.106 ;my PTR record
IN MX 0 . ;explicitly states not ever legal ***@xxx
IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf

host2.example.com IN A 193.120.238.109 ;my PTR record
IN MX 0 . ;explicitly states not ever legal ***@xxx
IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf

host3.example.com IN A 195.2.202.64 ;my PTR record
IN MX 0 . ;explicitly states not ever legal ***@xxx
IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf

host3a.example.com IN A 195.2.202.40 ;my PTR record
IN MX 0 . ;explicitly states not ever legal ***@xxx
IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf


host1.mxout.example.com IN A 193.120.238.106 ;my mailservers outgoing/sending helo-id and
;where postmaster@ messages come from
IN MX 10 mx10.example.com
IN MX 20 mx20.example.com
IN TXT "v=spf1 ip4:193.120.238.106 -all" ;explicitly states IT IS legal to spf

host2.mxout.example.com IN A 193.120.238.109 ;my mailservers outgoing/sending helo-id and
;where postmaster@ messages come from
IN MX 10 mx10.example.com
IN MX 20 mx20.example.com
IN TXT "v=spf1 ip4:193.120.238.109 -all" ;explicitly states IT IS legal to spf

host3.mxout.example.com IN A 195.2.202.63 ;my mailservers outgoing/sending helo-id and
IN A 195.2.202.40 ;where postmaster@ messages come from
IN MX 10 mx10.example.com
IN MX 20 mx20.example.com
IN TXT "v=spf1 ip4:195.2.202.63 ip4:195.2.202.40 -all" ;explicitly states IT IS legal to spf

_client._smtp.host1.mxout.example.com SRV 1 2 1 host1.mxout.example.com.
_client._smtp.host2.mxout.example.com SRV 1 2 1 host2.mxout.example.com.
_client._smtp.host3.mxout.example.com SRV 1 2 1 host3.mxout.example.com.

_client._smtp.example.com SRV 1 1 1 example.com.

;the _client._smtp lines authorised the three listed names to be used in helo and deauthorise any other using an old/unused protocol called csv, but as it costs nothing i still use it as it was well designed

<http://en.wikipedia.org/wiki/Certified_Server_Validation>http://en.wikipedia.org/wiki/Certified_Server_Validation

[Roman Gelfand]

consider the follwoing situation...

A user sends email with from: address as ***@domain.com. The
domain.com doesn't have spf txt record. The smtp server used to send
this email is mx1.anotherdomai.com. This domain has spf txt record.
Are you saying spf checker on the destination smtp server is going to
know to check the source smtp host for spf txt record? If so, what
happens when there is clash between domain.com's spf txt record and
that of mx1.anotherdomai.com where domain.com forbids the smtp host
from sending the email and mx1.anotherdomai.com allows? In terms of
not ending up in the destination spam box, which one is more preferred
by the spf checker? spf txt record for domain.com or
mx1.anotherdomai.com?

On Tue, Sep 10, 2013 at 7:18 AM, alan <***@alandoherty.net> wrote:
> At 01:04 10/09/2013 Tuesday, you wrote:
>>On 09/09/2013 07:22 PM, Roman Gelfand wrote:
>>>thanks for all the help. I still have a couple of questions...
>>>
>>>1. Can you have more than 1 spf txt records for a domain?
>>Absolutely not.
>>>2. What does putting host name before v=spf1 do for us? is that
>>>somehow used in conjunction with helo? Can you have multiple host
>>>names separated by spaces before v=spf1?
>>That is the syntax used by the BIND family of DNS servers used to indicate which domain the record is for. The syntax used by your DNS server may vary. The BIND syntax is the canonical syntax used for discussing DNS records via email. You should learn it.
>>
>>>3. I am not quite sure what you mean by ...
>>>if they are the same machine then you should investigate and compile a
>>>list of all its ips so that you can pass the common (does helo ==
>>>ip-in-A-of-helo test many receivers perform to weed out bots)
>>>could you give an example.
>>Suppose the mail server uses mail1.example.com as its HELO name, and has IPs 192.0.2.1 and 198.51.100.3 (is on two different ISPs). Then the HELO SPF record could be
>>
>>mail1.example.com IN TXT "v=spf1 ip4:192.0.2.1 ip4:198.51.100.3 -all"
>>
>>Or possibly:
>>
>>mail1.example.com IN TXT "v=spf1 a -all"
>> IN A 192.0.2.1
>> IN A 198.51.100.3
>
>
> or to put it another way every hostname IS a domain (in dns terms)
>
> thus in my case the SPF for my example domain (below)
> as my real SPF records are to complex/experimental and the domains are to
>
> but feel free to actually check the real domains alandoherty.net and alan.gothic.ie and the provider domain orionnetworks.ie that the servers are part of
>
> but basically their are 3 mailservers
> and in this example i have given one 2 ips (all ips are my own so should not annoy anyone)
> (but as all are well secured by automatons probing them may result in autoblacklisting)
>
> example.com IN A 193.120.238.106 ;my webserver/mailserver
> IN MX 10 mx10.example.com ;my mailservers answering/25 helo-id and TLS cert
> IN MX 20 mx20.example.com ;my other mailservers answering/25 helo-id and TLS cert
> IN MX 20 mx30.example.com ;my other mailservers answering/25 helo-id and TLS cert
> IN TXT "v=spf1 ip4:193.120.238.109 ip4:193.120.238.106 ip4:195.2.202.63 ip4:195.2.202.40 -all"
> IN TXT "spf2.0/mfrom ip4:193.120.238.109 ip4:193.120.238.106 ip4:195.2.202.63 ip4:195.2.202.40 -all"
> IN TXT "spf2.0/pra ip4:193.120.238.109 ip4:193.120.238.106 ip4:195.2.202.63 ip4:195.2.202.40 ?all"
> ;last 2 lines just for the broken sender-id checkers to ensure they do not block mail via mailinglists
>
> www.example.com IN A 193.120.238.106 ;my webserver
> IN MX 0 . ;explicitly states not ever legal ***@xxx
> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>
> some-desktop.example.com IN A 193.120.xx.xx ;a machine
> IN MX 0 . ;explicitly states not ever legal ***@xxx
> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>
> support.example.com IN A 193.120.238.106 ;another website
> IN MX 0 . ;explicitly states not ever legal ***@xxx
> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>
> smtps.example.com IN A 193.120.238.106 ;my mailservers answering/587 helo-id and TLS cert
> IN A 193.120.238.109 ;used by clients to send/relay mail outward
> IN MX 0 . ;explicitly states not ever legal ***@xxx
> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>
> mx10.example.com IN A 193.120.238.109 ;my mailserver incomming
> IN MX 0 . ;explicitly states not ever legal ***@xxx
> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>
> mx20.example.com IN A 193.120.238.106 ;my mailserver incomming
> IN MX 0 . ;explicitly states not ever legal ***@xxx
> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>
> mx30.example.com IN A 195.2.202.63 ;my mailserver incomming
> IN A 195.2.202.40
> IN MX 0 . ;explicitly states not ever legal ***@xxx
> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>
> host1.example.com IN A 193.120.238.106 ;my PTR record
> IN MX 0 . ;explicitly states not ever legal ***@xxx
> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>
> host2.example.com IN A 193.120.238.109 ;my PTR record
> IN MX 0 . ;explicitly states not ever legal ***@xxx
> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>
> host3.example.com IN A 195.2.202.64 ;my PTR record
> IN MX 0 . ;explicitly states not ever legal ***@xxx
> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>
> host3a.example.com IN A 195.2.202.40 ;my PTR record
> IN MX 0 . ;explicitly states not ever legal ***@xxx
> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>
>
> host1.mxout.example.com IN A 193.120.238.106 ;my mailservers outgoing/sending helo-id and
> ;where postmaster@ messages come from
> IN MX 10 mx10.example.com
> IN MX 20 mx20.example.com
> IN TXT "v=spf1 ip4:193.120.238.106 -all" ;explicitly states IT IS legal to spf
>
> host2.mxout.example.com IN A 193.120.238.109 ;my mailservers outgoing/sending helo-id and
> ;where postmaster@ messages come from
> IN MX 10 mx10.example.com
> IN MX 20 mx20.example.com
> IN TXT "v=spf1 ip4:193.120.238.109 -all" ;explicitly states IT IS legal to spf
>
> host3.mxout.example.com IN A 195.2.202.63 ;my mailservers outgoing/sending helo-id and
> IN A 195.2.202.40 ;where postmaster@ messages come from
> IN MX 10 mx10.example.com
> IN MX 20 mx20.example.com
> IN TXT "v=spf1 ip4:195.2.202.63 ip4:195.2.202.40 -all" ;explicitly states IT IS legal to spf
>
> _client._smtp.host1.mxout.example.com SRV 1 2 1 host1.mxout.example.com.
> _client._smtp.host2.mxout.example.com SRV 1 2 1 host2.mxout.example.com.
> _client._smtp.host3.mxout.example.com SRV 1 2 1 host3.mxout.example.com.
>
> _client._smtp.example.com SRV 1 1 1 example.com.
>
> ;the _client._smtp lines authorised the three listed names to be used in helo and deauthorise any other using an old/unused protocol called csv, but as it costs nothing i still use it as it was well designed
>
> <http://en.wikipedia.org/wiki/Certified_Server_Validation>http://en.wikipedia.org/wiki/Certified_Server_Validation
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
> Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
> Modify Your Subscription: https://www.listbox.com/member/?&
> Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130910071903:C73359B6-1A0A-11E3-9EE6-CC300201D417
> Powered by Listbox: http://www.listbox.com

[alan]

At 19:52 12/09/2013 Thursday, Roman Gelfand wrote:
>consider the follwoing situation...
>
>A user sends email with from: address as ***@domain.com. The
>domain.com doesn't have spf txt record. The smtp server used to send
>this email is mx1.anotherdomai.com. This domain has spf txt record.
>Are you saying spf checker on the destination smtp server is going to
>know to check the source smtp host for spf txt record?

it checks both the ***@domain.com's spf (result neutral no spf)
and helo-id's spf record (result pass so it can assume safely that the email is not from a botnet and thus gets a less suspicious spam-score usually)

> If so, what happens when there is clash between domain.com's spf txt record and
>that of mx1.anotherdomai.com where domain.com forbids the smtp host
>from sending the email and mx1.anotherdomai.com allows?

mx1.anotherdomai.com allows only the HELO much earlier in the transaction so if we assume it passed

the ***@domain.com's spf if it hardfails declares that a user of the non-forged server mx1.anotherdomai.com is attempting to forge mail from ***@domain.com and thus obviously the email should be rejected

if on the other hand ***@domain.com's spf passes but the server helo'd as mx1.anotherdomain.com and that hardfailed then its down to the policy at the receiving site (as it always is) we here will not accept mail from forged servers (or ones so badly administered they appear forged)

> In terms of not ending up in the destination spam box, which one is more preferred
>by the spf checker?

thats down to their policy, for us an spf hardfail never goes to spam folder its 5xx refused and never comes into the system
(as spf is designed to be checked before the mail has been transferred)

spf none and spf softfail and neutral do make the mail more likely to goto the spamfolder in co-operation with later content-checks
spf-pass equally does make the mail slightly less likely to go into the spamfolder if the domain is itself is on a 'reputable' list

>spf txt record for domain.com or
>mx1.anotherdomai.com?

you have failed to understand the two seperate uses of spf

A spf for helo
the spf record for the name that a server uses in its helo greeting
(authenticates that ip to claim to be that server, if the name is used from another the server name is forged)

(should only ever terminate -all, if it terminates ?all or ~all or +all we tend to regard it as suspicious and thus treat as such)

It says everything about the sending server and asserts nothing about the sending user

B spf for the envelope sender
the spf for the domain used in the envelope sender
(authenticates which ips can send email from users at that domain, if the user is seen from another ip the user is forged)

(can legitimately be terminated in any way and can be considerably complex)

It says everything about the sending user nothing about the sending server (other than the user is allowed to use it)

C
the from: address from the from: header in email
(not used in any way by any part of spf)



(for step A people also authenticate via CSV, checking that the PTR>a>IP (FcrDNS), and other forms of validity testing)
(for step B there is no other trustable method other than SPF Im aware of)
(for step C there is DKIM and the very failed and very flawed sender-ID(do-not-use))







>On Tue, Sep 10, 2013 at 7:18 AM, alan <***@alandoherty.net> wrote:
>> At 01:04 10/09/2013 Tuesday, you wrote:
>>>On 09/09/2013 07:22 PM, Roman Gelfand wrote:
>>>>thanks for all the help. I still have a couple of questions...
>>>>
>>>>1. Can you have more than 1 spf txt records for a domain?
>>>Absolutely not.
>>>>2. What does putting host name before v=spf1 do for us? is that
>>>>somehow used in conjunction with helo? Can you have multiple host
>>>>names separated by spaces before v=spf1?
>>>That is the syntax used by the BIND family of DNS servers used to indicate which domain the record is for. The syntax used by your DNS server may vary. The BIND syntax is the canonical syntax used for discussing DNS records via email. You should learn it.
>>>
>>>>3. I am not quite sure what you mean by ...
>>>>if they are the same machine then you should investigate and compile a
>>>>list of all its ips so that you can pass the common (does helo ==
>>>>ip-in-A-of-helo test many receivers perform to weed out bots)
>>>>could you give an example.
>>>Suppose the mail server uses mail1.example.com as its HELO name, and has IPs 192.0.2.1 and 198.51.100.3 (is on two different ISPs). Then the HELO SPF record could be
>>>
>>>mail1.example.com IN TXT "v=spf1 ip4:192.0.2.1 ip4:198.51.100.3 -all"
>>>
>>>Or possibly:
>>>
>>>mail1.example.com IN TXT "v=spf1 a -all"
>>> IN A 192.0.2.1
>>> IN A 198.51.100.3
>>
>>
>> or to put it another way every hostname IS a domain (in dns terms)
>>
>> thus in my case the SPF for my example domain (below)
>> as my real SPF records are to complex/experimental and the domains are to
>>
>> but feel free to actually check the real domains alandoherty.net and alan.gothic.ie and the provider domain orionnetworks.ie that the servers are part of
>>
>> but basically their are 3 mailservers
>> and in this example i have given one 2 ips (all ips are my own so should not annoy anyone)
>> (but as all are well secured by automatons probing them may result in autoblacklisting)
>>
>> example.com IN A 193.120.238.106 ;my webserver/mailserver
>> IN MX 10 mx10.example.com ;my mailservers answering/25 helo-id and TLS cert
>> IN MX 20 mx20.example.com ;my other mailservers answering/25 helo-id and TLS cert
>> IN MX 20 mx30.example.com ;my other mailservers answering/25 helo-id and TLS cert
>> IN TXT "v=spf1 ip4:193.120.238.109 ip4:193.120.238.106 ip4:195.2.202.63 ip4:195.2.202.40 -all"
>> IN TXT "spf2.0/mfrom ip4:193.120.238.109 ip4:193.120.238.106 ip4:195.2.202.63 ip4:195.2.202.40 -all"
>> IN TXT "spf2.0/pra ip4:193.120.238.109 ip4:193.120.238.106 ip4:195.2.202.63 ip4:195.2.202.40 ?all"
>> ;last 2 lines just for the broken sender-id checkers to ensure they do not block mail via mailinglists
>>
>> www.example.com IN A 193.120.238.106 ;my webserver
>> IN MX 0 . ;explicitly states not ever legal ***@xxx
>> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>>
>> some-desktop.example.com IN A 193.120.xx.xx ;a machine
>> IN MX 0 . ;explicitly states not ever legal ***@xxx
>> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>>
>> support.example.com IN A 193.120.238.106 ;another website
>> IN MX 0 . ;explicitly states not ever legal ***@xxx
>> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>>
>> smtps.example.com IN A 193.120.238.106 ;my mailservers answering/587 helo-id and TLS cert
>> IN A 193.120.238.109 ;used by clients to send/relay mail outward
>> IN MX 0 . ;explicitly states not ever legal ***@xxx
>> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>>
>> mx10.example.com IN A 193.120.238.109 ;my mailserver incomming
>> IN MX 0 . ;explicitly states not ever legal ***@xxx
>> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>>
>> mx20.example.com IN A 193.120.238.106 ;my mailserver incomming
>> IN MX 0 . ;explicitly states not ever legal ***@xxx
>> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>>
>> mx30.example.com IN A 195.2.202.63 ;my mailserver incomming
>> IN A 195.2.202.40
>> IN MX 0 . ;explicitly states not ever legal ***@xxx
>> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>>
>> host1.example.com IN A 193.120.238.106 ;my PTR record
>> IN MX 0 . ;explicitly states not ever legal ***@xxx
>> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>>
>> host2.example.com IN A 193.120.238.109 ;my PTR record
>> IN MX 0 . ;explicitly states not ever legal ***@xxx
>> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>>
>> host3.example.com IN A 195.2.202.64 ;my PTR record
>> IN MX 0 . ;explicitly states not ever legal ***@xxx
>> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>>
>> host3a.example.com IN A 195.2.202.40 ;my PTR record
>> IN MX 0 . ;explicitly states not ever legal ***@xxx
>> IN TXT "v=spf1 -all" ;explicitly states not ever legal to spf
>>
>>
>> host1.mxout.example.com IN A 193.120.238.106 ;my mailservers outgoing/sending helo-id and
>> ;where postmaster@ messages come from
>> IN MX 10 mx10.example.com
>> IN MX 20 mx20.example.com
>> IN TXT "v=spf1 ip4:193.120.238.106 -all" ;explicitly states IT IS legal to spf
>>
>> host2.mxout.example.com IN A 193.120.238.109 ;my mailservers outgoing/sending helo-id and
>> ;where postmaster@ messages come from
>> IN MX 10 mx10.example.com
>> IN MX 20 mx20.example.com
>> IN TXT "v=spf1 ip4:193.120.238.109 -all" ;explicitly states IT IS legal to spf
>>
>> host3.mxout.example.com IN A 195.2.202.63 ;my mailservers outgoing/sending helo-id and
>> IN A 195.2.202.40 ;where postmaster@ messages come from
>> IN MX 10 mx10.example.com
>> IN MX 20 mx20.example.com
>> IN TXT "v=spf1 ip4:195.2.202.63 ip4:195.2.202.40 -all" ;explicitly states IT IS legal to spf
>>
>> _client._smtp.host1.mxout.example.com SRV 1 2 1 host1.mxout.example.com.
>> _client._smtp.host2.mxout.example.com SRV 1 2 1 host2.mxout.example.com.
>> _client._smtp.host3.mxout.example.com SRV 1 2 1 host3.mxout.example.com.
>>
>> _client._smtp.example.com SRV 1 1 1 example.com.
>>
>> ;the _client._smtp lines authorised the three listed names to be used in helo and deauthorise any other using an old/unused protocol called csv, but as it costs nothing i still use it as it was well designed
>>
>> <http://en.wikipedia.org/wiki/Certified_Server_Validation>http://en.wikipedia.org/wiki/Certified_Server_Validation
>>
>>
>>
>> -------------------------------------------
>> Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>> Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>
>> Archives: https://www.listbox.com/member/archive/735/=now
>> RSS Feed: https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
>> Modify Your Subscription: https://www.listbox.com/member/?&
>> Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130910071903:C73359B6-1A0A-11E3-9EE6-CC300201D417
>> Powered by Listbox: http://www.listbox.com
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/735/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130912145239:7B620B08-1BDC-11E3-8577-C03EB1F05C8B
>Powered by Listbox: http://www.listbox.com

[Scott Kitterman]

It's a matter of local policy for the receiver. There no standard. RFC 4408
is, intentionally, very light on receiver policy.

Scott K

On Thursday, September 12, 2013 14:52:29 Roman Gelfand wrote:
> consider the follwoing situation...
>
> A user sends email with from: address as ***@domain.com. The
> domain.com doesn't have spf txt record. The smtp server used to send
> this email is mx1.anotherdomai.com. This domain has spf txt record.
> Are you saying spf checker on the destination smtp server is going to
> know to check the source smtp host for spf txt record? If so, what
> happens when there is clash between domain.com's spf txt record and
> that of mx1.anotherdomai.com where domain.com forbids the smtp host
> from sending the email and mx1.anotherdomai.com allows? In terms of
> not ending up in the destination spam box, which one is more preferred
> by the spf checker? spf txt record for domain.com or
> mx1.anotherdomai.com?
>
> On Tue, Sep 10, 2013 at 7:18 AM, alan <***@alandoherty.net> wrote:
> > At 01:04 10/09/2013 Tuesday, you wrote:
> >>On 09/09/2013 07:22 PM, Roman Gelfand wrote:
> >>>thanks for all the help. I still have a couple of questions...
> >>>
> >>>1. Can you have more than 1 spf txt records for a domain?
> >>
> >>Absolutely not.
> >>
> >>>2. What does putting host name before v=spf1 do for us? is that
> >>>somehow used in conjunction with helo? Can you have multiple host
> >>>names separated by spaces before v=spf1?
> >>
> >>That is the syntax used by the BIND family of DNS servers used to indicate
> >>which domain the record is for. The syntax used by your DNS server may
> >>vary. The BIND syntax is the canonical syntax used for discussing DNS
> >>records via email. You should learn it.>>
> >>>3. I am not quite sure what you mean by ...
> >>>if they are the same machine then you should investigate and compile a
> >>>list of all its ips so that you can pass the common (does helo ==
> >>>ip-in-A-of-helo test many receivers perform to weed out bots)
> >>>could you give an example.
> >>
> >>Suppose the mail server uses mail1.example.com as its HELO name, and has
> >>IPs 192.0.2.1 and 198.51.100.3 (is on two different ISPs). Then the HELO
> >>SPF record could be
> >>
> >>mail1.example.com IN TXT "v=spf1 ip4:192.0.2.1 ip4:198.51.100.3 -all"
> >>
> >>Or possibly:
> >>
> >>mail1.example.com IN TXT "v=spf1 a -all"
> >>
> >> IN A 192.0.2.1
> >> IN A 198.51.100.3
> >
> > or to put it another way every hostname IS a domain (in dns terms)
> >
> > thus in my case the SPF for my example domain (below)
> > as my real SPF records are to complex/experimental and the domains are to
> >
> > but feel free to actually check the real domains alandoherty.net and
> > alan.gothic.ie and the provider domain orionnetworks.ie that the servers
> > are part of
> >
> > but basically their are 3 mailservers
> > and in this example i have given one 2 ips (all ips are my own so should
> > not annoy anyone) (but as all are well secured by automatons probing them
> > may result in autoblacklisting)
> >
> > example.com IN A 193.120.238.106 ;my
> > webserver/mailserver
> >
> > IN MX 10 mx10.example.com ;my mailservers
> > answering/25 helo-id and TLS cert IN MX 20
> > mx20.example.com ;my other mailservers answering/25
> > helo-id and TLS cert IN MX 20 mx30.example.com ;my
> > other mailservers answering/25 helo-id and TLS cert>
> > IN TXT "v=spf1 ip4:193.120.238.109 ip4:193.120.238.106
> > ip4:195.2.202.63 ip4:195.2.202.40 -all">
> > IN TXT "spf2.0/mfrom ip4:193.120.238.109 ip4:193.120.238.106
> > ip4:195.2.202.63 ip4:195.2.202.40 -all">
> > IN TXT "spf2.0/pra ip4:193.120.238.109 ip4:193.120.238.106
> > ip4:195.2.202.63 ip4:195.2.202.40 ?all">
> > ;last 2 lines just for the broken sender-id checkers
> > to ensure they do not block mail via mailinglists>
> > www.example.com IN A 193.120.238.106 ;my webserver
> >
> > IN MX 0 . ;explicitly states
> > not ever legal ***@xxx
> > IN TXT "v=spf1 -all" ;explicitly states
> > not ever legal to spf
> >
> > some-desktop.example.com IN A 193.120.xx.xx ;a machine
> >
> > IN MX 0 . ;explicitly states
> > not ever legal ***@xxx
> > IN TXT "v=spf1 -all" ;explicitly states
> > not ever legal to spf
> >
> > support.example.com IN A 193.120.238.106 ;another website
> >
> > IN MX 0 . ;explicitly states
> > not ever legal ***@xxx
> > IN TXT "v=spf1 -all" ;explicitly states
> > not ever legal to spf
> >
> > smtps.example.com IN A 193.120.238.106 ;my mailservers
> > answering/587 helo-id and TLS cert>
> > IN A 193.120.238.109 ;used by clients to
> > send/relay mail outward
> > IN MX 0 . ;explicitly states
> > not ever legal ***@xxx
> > IN TXT "v=spf1 -all" ;explicitly states
> > not ever legal to spf
> >
> > mx10.example.com IN A 193.120.238.109 ;my mailserver
> > incomming>
> > IN MX 0 . ;explicitly states
> > not ever legal ***@xxx
> > IN TXT "v=spf1 -all" ;explicitly states
> > not ever legal to spf
> >
> > mx20.example.com IN A 193.120.238.106 ;my mailserver
> > incomming>
> > IN MX 0 . ;explicitly states
> > not ever legal ***@xxx
> > IN TXT "v=spf1 -all" ;explicitly states
> > not ever legal to spf
> >
> > mx30.example.com IN A 195.2.202.63 ;my mailserver
> > incomming>
> > IN A 195.2.202.40
> > IN MX 0 . ;explicitly states
> > not ever legal ***@xxx
> > IN TXT "v=spf1 -all" ;explicitly states
> > not ever legal to spf
> >
> > host1.example.com IN A 193.120.238.106 ;my PTR record
> >
> > IN MX 0 . ;explicitly states
> > not ever legal ***@xxx
> > IN TXT "v=spf1 -all" ;explicitly states
> > not ever legal to spf
> >
> > host2.example.com IN A 193.120.238.109 ;my PTR record
> >
> > IN MX 0 . ;explicitly states
> > not ever legal ***@xxx
> > IN TXT "v=spf1 -all" ;explicitly states
> > not ever legal to spf
> >
> > host3.example.com IN A 195.2.202.64 ;my PTR record
> >
> > IN MX 0 . ;explicitly states
> > not ever legal ***@xxx
> > IN TXT "v=spf1 -all" ;explicitly states
> > not ever legal to spf
> >
> > host3a.example.com IN A 195.2.202.40 ;my PTR record
> >
> > IN MX 0 . ;explicitly states
> > not ever legal ***@xxx
> > IN TXT "v=spf1 -all" ;explicitly states
> > not ever legal to spf
> >
> > host1.mxout.example.com IN A 193.120.238.106 ;my mailservers
> > outgoing/sending helo-id and>
> > ;where postmaster@
> > messages come
> > from
> >
> > IN MX 10 mx10.example.com
> > IN MX 20 mx20.example.com
> >
> > IN TXT "v=spf1 ip4:193.120.238.106 -all" ;explicitly
> > states IT IS legal to spf>
> > host2.mxout.example.com IN A 193.120.238.109 ;my mailservers
> > outgoing/sending helo-id and>
> > ;where postmaster@
> > messages come
> > from
> >
> > IN MX 10 mx10.example.com
> > IN MX 20 mx20.example.com
> >
> > IN TXT "v=spf1 ip4:193.120.238.109 -all" ;explicitly
> > states IT IS legal to spf>
> > host3.mxout.example.com IN A 195.2.202.63 ;my mailservers
> > outgoing/sending helo-id and>
> > IN A 195.2.202.40 ;where postmaster@
> > messages come from
> > IN MX 10 mx10.example.com
> > IN MX 20 mx20.example.com
> >
> > IN TXT "v=spf1 ip4:195.2.202.63 ip4:195.2.202.40 -all"
> > ;explicitly states IT IS legal to spf>
> > _client._smtp.host1.mxout.example.com SRV 1 2 1
> > host1.mxout.example.com. _client._smtp.host2.mxout.example.com
> > SRV 1 2 1 host2.mxout.example.com.
> > _client._smtp.host3.mxout.example.com SRV 1 2 1
> > host3.mxout.example.com.
> >
> > _client._smtp.example.com SRV 1 1 1 example.com.
> >
> > ;the _client._smtp lines authorised the three listed names to be used in
> > helo and deauthorise any other using an old/unused protocol called csv,
> > but as it costs nothing i still use it as it was well designed
> >
> > <http://en.wikipedia.org/wiki/Certified_Server_Validation>http://en.wikipe
> > dia.org/wiki/Certified_Server_Validation

[Sanford Whiteman]

> A user sends email with from: address as ***@domain.com. The
> domain.com doesn't have spf txt record. The smtp server used to send
> this email is mx1.anotherdomai.com.

First, not to sound Clintonian, but let's agree on the definition of
"is." My response applies when "is <hostname>" means "uses the
HELO/EHLO value <hostname>".

(That is, it _does not_ apply when "is" means "has a PTR pointing to
<hostname>" other possible meanings.)

> Are you saying spf checker on the destination smtp server is going to
> know to check the source smtp host for spf txt record?

The smtp-sender is providing its hostname to the smtp-receiver using
the HELO command.

The SPF standard does not _require_ that an smtp-receiver that is
claimed to "support SPF" (or "honor SPF," whatever) do anything with
the HELO. The standard only requires that the domain of the envelope
sender be checked, but also _recommends_ that a receiver checks HELO.

Regardless, you must be prepared, if you as a sender claim to "use
SPF" (or "publish SPF," or whatever terminology that implies that you
think SPF is useful) to have your HELO hostname looked up. The HELO
lookup amounts to checking if postmaster@<hostname> would be allowed
to send from the sender IP.

> If so, what happens when there is clash between domain.com's spf txt record and
> that of mx1.anotherdomai.com where domain.com forbids the smtp host
> from sending the email and mx1.anotherdomai.com allows?

In the case of "forbidding" (meaning hard fail) there isn't really any
such thing as a "clash." Hard fail on one would typically have veto
power, because that literally means "not allowed" -- what part of "not
allowed" would the sender not understand? :) It is very unlikely that
there would be any kind of early-exit/ short-circuit mechanism that
would allow the recommended HELO check to both *run and fail* and not
end up with the whole message being rejected; likewise, if the
required MAIL FROM runs and fails the whole message is doomed.
(Imagine, if this more familiar to you, a list of firewall rules where
any Deny causes the connection to be denied, whereas an Allow just
falls through to the next rule, rather than exiting the rules
checker.)

When it comes to softfail/neutral/none from each check, it's up to the
receiver to decide who "wins" after computing the weights of every
test (which may at that point include content checks on the body of
the message). It may be that an SPF softfail only on the HELO isn't
penalized as much as an SPF softfail on the MAIL FROM (for the the
simple reason that a lot of people don't know about SPF checking the
HELO, so the HELO results may be more coincidental than deliberate).
But this is all up to the receiver's logic/wizardry/halfassedness.

Ultimately, you can't *know* what someone will do with your message,
but you can try to get the fullest understanding of SPF as you roll it
out. You may temporarily screw up your SPF -- we all do at times, just
as with any DNS stuff -- and get unwanted results, and you need to
know how to handle that. If you don't feel ready to handle
troubleshooting it live, maybe you aren't ready to publish SPF yet.

By way of consolation/warning, I learned the other week that at my
previous employer, a sysadmin got the bright idea to create multiple
TXT records to "spread out" the SPF info. If he had come to this list
first, we could've set him straight, but alas, he put this in place
and no one there (IT staff of 20), including that guy, is officially
responsible for DNS. The marketing staff is being more professional
about it than the techs (not a common scenario) while mail gets
bitbucketed all the time and everybody in the IT bullpen says users
are imagining things... I digress, but the point is SPF isn't as
simple as people think, and you have to at least charge yourself with
getting into DNS + SPF for a few weeks/months, or it's just going to
create technical debt -- technology that's in production, but you
never really grokked and aren't ready to troubleshoot. As an
unexpected consequence, you may choose to believe that a problem
couldn't be with the thing you didn't understand, because that would
mean you'd have to learn how it works after all this time. You don't
want to get into that situation.

> which one is more preferred by the spf checker? spf txt record for
> domain.com or mx1.anotherdomai.com?

Well, you MUST have the record for the MAIL FROM if receivers are
going to think you "use SPF" in the real world. But (to put it mildly)
not every sender puts SPF records in their DNS. Of any kind. So, for
example, having a pass record for the HELO, yet not having a record at
all for the MAIL FROM is lame and you shouldn't say you use SPF, but
it happens... and you may get away with it because there are a lot of
senders out there who are ignoring SPF completely.

Look at this way: you have at least 4 responsibilities when operating
an smtp-sender: to keep your services running and available, to be
ethical when it comes to unsolicited mail, to be proactive in not
allowing your domain to be abused... and to be upright in only
deploying technologies that you know reasonably well so you don't let
customers/clients down when there's a problem (which is really just
part of the first responsibility, but obviously I felt like harping on
it!).

-- Sandy

[Scott Kitterman]

On Thursday, September 12, 2013 16:46:28 you wrote:
> > A user sends email with from: address as ***@domain.com. The
> > domain.com doesn't have spf txt record. The smtp server used to send
> > this email is mx1.anotherdomai.com.
>
> First, not to sound Clintonian, but let's agree on the definition of
> "is." My response applies when "is <hostname>" means "uses the
> HELO/EHLO value <hostname>".
>
> (That is, it _does not_ apply when "is" means "has a PTR pointing to
> <hostname>" other possible meanings.)

That's correct.

> > Are you saying spf checker on the destination smtp server is going to
> > know to check the source smtp host for spf txt record?
>
> The smtp-sender is providing its hostname to the smtp-receiver using
> the HELO command.
>
> The SPF standard does not _require_ that an smtp-receiver that is
> claimed to "support SPF" (or "honor SPF," whatever) do anything with
> the HELO. The standard only requires that the domain of the envelope
> sender be checked, but also _recommends_ that a receiver checks HELO.

In one special case it does. If mail from is empty (it's a bounce), the mail
from check is performed with the pseudo mail from ***@hostname.

> Regardless, you must be prepared, if you as a sender claim to "use
> SPF" (or "publish SPF," or whatever terminology that implies that you
> think SPF is useful) to have your HELO hostname looked up. The HELO
> lookup amounts to checking if postmaster@<hostname> would be allowed
> to send from the sender IP.

There is a subtle distinction here. The postmaster@ construct is a synthetic
mail from used for bounces. When doing an independent HELO check as is
recommended in RFC 4408 and the current draft of 4408bis, there is no
localpart. It's the hostname only.

> > If so, what happens when there is clash between domain.com's spf txt
> > record and that of mx1.anotherdomai.com where domain.com forbids the smtp
> > host from sending the email and mx1.anotherdomai.com allows?
>
> In the case of "forbidding" (meaning hard fail) there isn't really any
> such thing as a "clash." Hard fail on one would typically have veto
> power, because that literally means "not allowed" -- what part of "not
> allowed" would the sender not understand? :) It is very unlikely that
> there would be any kind of early-exit/ short-circuit mechanism that
> would allow the recommended HELO check to both *run and fail* and not
> end up with the whole message being rejected; likewise, if the
> required MAIL FROM runs and fails the whole message is doomed.
> (Imagine, if this more familiar to you, a list of firewall rules where
> any Deny causes the connection to be denied, whereas an Allow just
> falls through to the next rule, rather than exiting the rules
> checker.)
>
> When it comes to softfail/neutral/none from each check, it's up to the
> receiver to decide who "wins" after computing the weights of every
> test (which may at that point include content checks on the body of
> the message). It may be that an SPF softfail only on the HELO isn't
> penalized as much as an SPF softfail on the MAIL FROM (for the the
> simple reason that a lot of people don't know about SPF checking the
> HELO, so the HELO results may be more coincidental than deliberate).
> But this is all up to the receiver's logic/wizardry/halfassedness.

In software I've written the default is to reject on Fail for Mail From and to
reject on Fail, Softfail, and Neutral for HELO checks. Since HELO checks
refer to a single host there's no issues like forwarding that make ?all or
~all records a rational thing for many domains.

> Ultimately, you can't *know* what someone will do with your message,
> but you can try to get the fullest understanding of SPF as you roll it
> out. You may temporarily screw up your SPF -- we all do at times, just
> as with any DNS stuff -- and get unwanted results, and you need to
> know how to handle that. If you don't feel ready to handle
> troubleshooting it live, maybe you aren't ready to publish SPF yet.

The other thing is that I've seen cases where receivers lied about why they
were rejecting things and claimed to be rejecting due to SPF when it was clear
based on the pattern of rejections that SPF had nothing to do with it.

> By way of consolation/warning, I learned the other week that at my
> previous employer, a sysadmin got the bright idea to create multiple
> TXT records to "spread out" the SPF info. If he had come to this list
> first, we could've set him straight, but alas, he put this in place
> and no one there (IT staff of 20), including that guy, is officially
> responsible for DNS. The marketing staff is being more professional
> about it than the techs (not a common scenario) while mail gets
> bitbucketed all the time and everybody in the IT bullpen says users
> are imagining things... I digress, but the point is SPF isn't as
> simple as people think, and you have to at least charge yourself with
> getting into DNS + SPF for a few weeks/months, or it's just going to
> create technical debt -- technology that's in production, but you
> never really grokked and aren't ready to troubleshoot. As an
> unexpected consequence, you may choose to believe that a problem
> couldn't be with the thing you didn't understand, because that would
> mean you'd have to learn how it works after all this time. You don't
> want to get into that situation.

I once heard about a company where the DNS admin decided his zone files would
look nicer if everything was lower case. Guess what that did to DKIM key
records? Some folks were not happy.

> > which one is more preferred by the spf checker? spf txt record for
> > domain.com or mx1.anotherdomai.com?
>
> Well, you MUST have the record for the MAIL FROM if receivers are
> going to think you "use SPF" in the real world. But (to put it mildly)
> not every sender puts SPF records in their DNS. Of any kind. So, for
> example, having a pass record for the HELO, yet not having a record at
> all for the MAIL FROM is lame and you shouldn't say you use SPF, but
> it happens... and you may get away with it because there are a lot of
> senders out there who are ignoring SPF completely.
>
> Look at this way: you have at least 4 responsibilities when operating
> an smtp-sender: to keep your services running and available, to be
> ethical when it comes to unsolicited mail, to be proactive in not
> allowing your domain to be abused... and to be upright in only
> deploying technologies that you know reasonably well so you don't let
> customers/clients down when there's a problem (which is really just
> part of the first responsibility, but obviously I felt like harping on
> it!).

I'd throw in generate RFC compliant mail too. That's the single most
important thing to get mail delivered that there is in my experience.

Scott K

[Sanford Whiteman]

>> The SPF standard does not _require_ that an smtp-receiver that is
>> claimed to "support SPF" (or "honor SPF," whatever) do anything with
>> the HELO. The standard only requires that the domain of the envelope
>> sender be checked, but also _recommends_ that a receiver checks HELO.

> In one special case it does. If mail from is empty (it's a bounce), the mail
> from check is performed with the pseudo mail from ***@hostname.

I actually was deliberately skipping when the HELO is checked as a
fallback mechanism w/null sender... only so much you can cram into one
already-overdone e-mail! But I should've been clear that HELO is
always recommended and in some cases required.

>> Regardless, you must be prepared, if you as a sender claim to "use
>> SPF" (or "publish SPF," or whatever terminology that implies that you
>> think SPF is useful) to have your HELO hostname looked up. The HELO
>> lookup amounts to checking if postmaster@<hostname> would be allowed
>> to send from the sender IP.

> There is a subtle distinction here. The postmaster@ construct is a synthetic
> mail from used for bounces. When doing an independent HELO check as is
> recommended in RFC 4408 and the current draft of 4408bis, there is no
> localpart. It's the hostname only.

Well clarified, just goes to show how even someone who's been on this
list since the beginning can be out of touch with the details.

When I gave 4408 a quick recheck before sending, I thought 4.3 -- "If
the <sender> has no localpart, substitute the string "postmaster" for
the localpart." -- applied to the independent and null-sender HELO
checks. I still don't exactly see where in 4408bis you clarify
otherwise, but I'll definitely take your word on it.

-- S.

[Scott Kitterman]

On Friday, September 13, 2013 00:20:25 you wrote:
> >> The SPF standard does not _require_ that an smtp-receiver that is
> >> claimed to "support SPF" (or "honor SPF," whatever) do anything with
> >> the HELO. The standard only requires that the domain of the envelope
> >> sender be checked, but also _recommends_ that a receiver checks HELO.
> >
> > In one special case it does. If mail from is empty (it's a bounce), the
> > mail from check is performed with the pseudo mail from
> > ***@hostname.
> I actually was deliberately skipping when the HELO is checked as a
> fallback mechanism w/null sender... only so much you can cram into one
> already-overdone e-mail! But I should've been clear that HELO is
> always recommended and in some cases required.
>
> >> Regardless, you must be prepared, if you as a sender claim to "use
> >> SPF" (or "publish SPF," or whatever terminology that implies that you
> >> think SPF is useful) to have your HELO hostname looked up. The HELO
> >> lookup amounts to checking if postmaster@<hostname> would be allowed
> >> to send from the sender IP.
> >
> > There is a subtle distinction here. The postmaster@ construct is a
> > synthetic mail from used for bounces. When doing an independent HELO
> > check as is recommended in RFC 4408 and the current draft of 4408bis,
> > there is no localpart. It's the hostname only.
>
> Well clarified, just goes to show how even someone who's been on this
> list since the beginning can be out of touch with the details.
>
> When I gave 4408 a quick recheck before sending, I thought 4.3 -- "If
> the <sender> has no localpart, substitute the string "postmaster" for
> the localpart." -- applied to the independent and null-sender HELO
> checks. I still don't exactly see where in 4408bis you clarify
> otherwise, but I'll definitely take your word on it.

No. You shouldn't.

I went back and looked (I was working from memory). Since the <sender> input
to check_host() can be either a Mail From or HELO identity, the postmaster@
applies to both.

I probably have code I need to fix now (not that it's likely to matter, the
local part is only relevant to macros which aren't commonly used).

Scott K

[Sanford Whiteman]

> I probably have code I need to fix now (not that it's likely to matter, the
> local part is only relevant to macros which aren't commonly used).

Ha, kindness gets results. :)

Cheers,

-- S.

[Stuart Gathman]

On 09/09/2013 01:00 PM, Roman Gelfand wrote:
> The ip it failed on is 24.38.11.30.
Wrong. The ip is failed on is 24.38.119.30, which is not in the list.

spf=hardfail (google.com: domain ***@unbeatablesale.com
does not designate 24.38.119.30 as permitted sender)
smtp.mail=***@unbeatablesale.com

[Dejan Petrovic]

I can see this is resolved, just my 2c :

98.136.0.0 - 98.136.196.255 (wow) is actually :
98.136.0.0 - 98.139.255.255 (WOW - big one)

My recommendation actually is to us ~all temporary, keep it for some time
until you find what really need, then make better definition and revert to
-all

Also, if you are using huge block because of big ISP dynamic IP range, I
am almost sure you can made it smaller, or use reverse like I did (with
some dynamic dns). Keep in mind that IP4 should be on line start and
something ugly like I did at end, I have dynamic IP, check mine as
example. I mean : mine is ugly because of dynamic dns and 60 sec :)

Regards,
Dejan

-----Original Message-----
From: alan <***@alandoherty.net>
To: spf-***@listbox.com
Date: Mon, 09 Sep 2013 17:48:06 +0100
Subject: Re: [spf-discuss] SPF Record Issue

> At 17:10 09/09/2013 Monday, Roman Gelfand wrote:
> >Yep, you are right. The domain name is unbeatablesale.com
>
> ok
> unbeatablesale.com text = "v=spf1 ip4:98.136.0.0/14
> ip4:24.187.208.80/29 ip4:24.38.11.24/29 ip4:108.58.151.0/29 -all"
>
> that is
> 98.136.0.0 - 98.136.196.255 (wow)
> 24.187.208.80 - 24.187.208.87
> 24.38.11.24 - 24.38.11.31
> 108.58.151.0 - 108.58.151.7
>
> now what ip is appearing to fail?
>
> as no there is no limit on the number of subnets other than the limits
> of how many text characters in a typical dns txt reply
> (you are way short of running into this limit thus not a concern)
>
> could you include the pass/fail output of whatever tester was in use?
>
> as it could be reporting not the failure of the spf check on the sender
> ***@unbeatablesale.com
> but an spf fail on the domain in the sending systems helo-id (which is
> a separate test entirely)
>
>
>
>
> >On Mon, Sep 9, 2013 at 12:01 PM, Stuart Gathman <***@gathman.org>
> wrote:
> >> On 09/09/2013 11:52 AM, Roman Gelfand wrote:
> >>>
> >>> I have added the spf text record, below. The first and second
> subnets
> >>> are being checked. However, when sending email from 3rd and 4th
> >>> subnet, spf check fails. Does this mean only 2 subnets could be
> >>> specified. If so, what to when there is more subnets?
> >>>
> >>> v=spf1 ip4:xx.xxx.0.0/14 ip4:24.yy.yyy.yyy.80/29 ip4:zz.zz.zz.24/29
> >>
> >> The second ip4 has 5 octets. That MUST get PermErr for any IP
> (but
> >> whatever you are checking with may not be fully conformant.) On the
> other
> >> hand, that may just be a typo when obfuscating the record. You are
> >> publishing the record in DNS, for crying out loud, so just give us
> the
> >> actual record. Also, people sometimes have trouble with TXT records
> on
> >> their DNS host, so you should load the record into a
> test.yourdomain.com
> >> domain on the same DNS server you will be using for production.
> Then we can
> >> check that it is actually served correctly.
> >>>
> >>> ip4:uuu.uu.uuu.0/29 -all
> >>
> >>
> >>
> >>
> >> -------------------------------------------
> >> Sender Policy Framework: http://www.openspf.net
> [http://www.openspf.net]
> >> Modify Your Subscription: http://www.listbox.com/member/
> >> [http://www.listbox.com/member/]
> >>
> >> Archives: https://www.listbox.com/member/archive/735/=now
> >> RSS Feed:
> https://www.listbox.com/member/archive/rss/735/24896328-acfdfa29
> >> Modify Your Subscription:
> >> https://www.listbox.com/member/?&
> >> Unsubscribe Now:
> >>
> https://www.listbox.com/unsubscribe/?&&post_id=20130909120211:2B4082F0-
> 1969-11E3-B924-E2C56875045B
> >>
> >> Powered by Listbox: http://www.listbox.com
> >
> >
> >-------------------------------------------
> >Sender Policy Framework: http://www.openspf.net
> [http://www.openspf.net]
> >Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
> >
> >Archives: https://www.listbox.com/member/archive/735/=now
> >RSS Feed:
> https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
> >Modify Your Subscription: https://www.listbox.com/member/?&
> >Unsubscribe Now:
> https://www.listbox.com/unsubscribe/?&&post_id=20130909121059:682580A2-
> 196A-11E3-AEC7-E0792EE61468
> >Powered by Listbox: http://www.listbox.com
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.net
> [http://www.openspf.net]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed:
> https://www.listbox.com/member/archive/rss/735/1954667-c27b5fc5
> Modify Your Subscription:
> https://www.listbox.com/member/?&
> 7b77b
> Unsubscribe Now:
> https://www.listbox.com/unsubscribe/?&
> 7-b8af911c&post_id=20130909124817:9E65463E-196F-11E3-9A41-BF4B57BB7C94
> Powered by Listbox: http://www.listbox.com