Mailing List Archive

Neil Gunton wrote:
> Here's my current SPF record,
> generated a while back from an online wizard:
>
> "v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"

Sorry, I just checked again and while that is the SPF record for
nilspace.com, there is a more basic record for crazyguyonabike.com, as
follows in my bind config:

TXT "v=spf1 a mx ptr ~all"

For nilspace.com, there are two lines:

TXT "v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
SPF "v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"

Could this be affecting delivery of messages coming 'from' different
domains on the same server (same ip address)?

Not sure if all this is even relevant, but I just have a feeling I'm not
doing this quite right... any insight welcomed.

Thanks again,

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101130205349:DF73F338-FCED-11DF-8F60-5A9DF559ED1D
Powered by Listbox: http://www.listbox.com

At 01:53 01/12/2010 Wednesday, Neil Gunton wrote:
>Neil Gunton wrote:
>>Here's my current SPF record, generated a while back from an online wizard:
>>"v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>
>Sorry, I just checked again and while that is the SPF record for nilspace.com, there is a more basic record for crazyguyonabike.com, as follows in my bind config:
>
>TXT "v=spf1 a mx ptr ~all"
>
>For nilspace.com, there are two lines:
>
>TXT "v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>SPF "v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>
>Could this be affecting delivery of messages coming 'from' different domains on the same server (same ip address)?

yes either way both are broke see previous mail

use ip4 if you know the ip (you do)
use a if you know only the name (the ip changes)
never use mx
never ever use ptr

and always use in order of cost to reciever

ip4 then a then include: (and if you really have to then mx)



>Not sure if all this is even relevant, but I just have a feeling I'm not doing this quite right... any insight welcomed.
>
>Thanks again,
>
>Neil
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/15739084-a04d3caa
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101130205349:DF73F338-FCED-11DF-8F60-5A9DF559ED1D
>Powered by Listbox: http://www.listbox.com



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101130223204:8FF6F69E-FCFB-11DF-8C0E-88C9C3A31EF1
Powered by Listbox: http://www.listbox.com

Ho ricevuto il messaggio. Sono in ferie fino al 16 dicembre, legger� il messaggio al mio rientro il 17 dicembre.
Per cose urgenti potete scrivere a info@biatwork.com, i miei colleghi prenderanno in carico la vostra email.

Cordiali saluti
Massimo Gregori





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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101130223429:E6A31EF0-FCFB-11DF-8FB7-E02CC6F4DBAC
Powered by Listbox: http://www.listbox.com

alan wrote:
> At 01:53 01/12/2010 Wednesday, Neil Gunton wrote:
>> Neil Gunton wrote:
>>> Here's my current SPF record, generated a while back from an online wizard:
>>> "v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>> Sorry, I just checked again and while that is the SPF record for nilspace.com, there is a more basic record for crazyguyonabike.com, as follows in my bind config:
>>
>> TXT "v=spf1 a mx ptr ~all"
>>
>> For nilspace.com, there are two lines:
>>
>> TXT "v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>> SPF "v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>>
>> Could this be affecting delivery of messages coming 'from' different domains on the same server (same ip address)?
>
> yes either way both are broke see previous mail

By "broke", do you mean my current entries might explain why my emails
aren't getting through to some email providers? I.e. because they look
for SPF records, and find mine, which are somehow messed up and make
them reject the email? Or just broke as in not doing anything useful?

> use ip4 if you know the ip (you do)
> use a if you know only the name (the ip changes)
> never use mx
> never ever use ptr
>
> and always use in order of cost to reciever
>
> ip4 then a then include: (and if you really have to then mx)

Ok, so do you mean I should just have the following for each domain:

"v=spf1 ip4:208.64.24.170 -all"

If so, should I have this in both a TXT and SPF entry for bind?

I just want to make this work so that my emails get delivered more
reliably, that's all. Is the above going to do it?

Thanks again,

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101201011745:B71ED004-FD12-11DF-8EAD-274FF559ED1D
Powered by Listbox: http://www.listbox.com

At 06:17 01/12/2010 Wednesday, Neil Gunton wrote:
>alan wrote:
>>At 01:53 01/12/2010 Wednesday, Neil Gunton wrote:
>>>Neil Gunton wrote:
>>>>Here's my current SPF record, generated a while back from an online wizard:
>>>>"v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>>>Sorry, I just checked again and while that is the SPF record for nilspace.com, there is a more basic record for crazyguyonabike.com, as follows in my bind config:
>>>
>>>TXT "v=spf1 a mx ptr ~all"
>>>
>>>For nilspace.com, there are two lines:
>>>
>>>TXT "v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>>>SPF "v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>>>
>>>Could this be affecting delivery of messages coming 'from' different domains on the same server (same ip address)?
>>yes either way both are broke see previous mail
>
>By "broke", do you mean my current entries might explain why my emails aren't getting through to some email providers? I.e. because they look for SPF records, and find mine, which are somehow messed up and make them reject the email? Or just broke as in not doing anything useful?

broke as in the first not the second, didn't you read my first reply which explained in detail
(resending in case)


>>use ip4 if you know the ip (you do)
>>use a if you know only the name (the ip changes)
>>never use mx
>>never ever use ptr
>>and always use in order of cost to reciever
>>ip4 then a then include: (and if you really have to then mx)
>
>Ok, so do you mean I should just have the following for each domain:
>
>"v=spf1 ip4:208.64.24.170 -all"

yes if your policy is -all (i would use ?all to test and then decide if i wanted ~all or -all once i has an understanding of the difference)


>If so, should I have this in both a TXT and SPF entry for bind?

yes TXT and SPF for both
(as all will see TXT , SPF is the new and future home for the records but not all can see SPF records yet, fewer can publish them, only supported in recent versions of bind on a few disributions)

>I just want to make this work so that my emails get delivered more reliably, that's all. Is the above going to do it?

spf will not ususlly fix deliverability issues (period)
broke spf (as in your case) will cause them.

as spf is how you tell the world 'its from me' or 'its a forger pretending to be me'
if it works they know its from you, they still don't know if they want mail from you
it it breaks it tells people its likely a forgery or a spammer (breaking SPF syntax to hope to slip past checks that 'fail-open' )


>Thanks again,
>
>Neil
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/15739084-a04d3caa
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101201011745:B71ED004-FD12-11DF-8EAD-274FF559ED1D
>Powered by Listbox: http://www.listbox.com



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101201050611:9E14A154-FD32-11DF-B8CA-FADDC5F4DBAC
Powered by Listbox: http://www.listbox.com

ok questions dealt with in reverse order as its late and only the last approached an SPF issue

first off your SPF

"v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"

utter bollix beyond useless and will get your mail dumped by any anti-spam system

starting from the fact you send all mail from one ip (spidey.nilspace.com)
should theirfore be
"v=spf1 ip4:208.64.24.170
then either ?all ~all or -all

and that is all
the a (waste of receivers resources as it will be the same ip
the mx (waste of receivers resources as it will be the same ip
the ptr (should never be used and will never match
the mx:spidey.nilspace.com (error breaking all as spidey.nilspace.com has no MX records
the +all (biggest mistake of all says "oh and we send from every ip in the world too" classic spammer and will get mail shot

now onto the rest

At 01:44 01/12/2010 Wednesday, Neil Gunton wrote:
>Hi, I'm sorry if this turns out to be a stupid question, but I'm having some trouble working out how to construct my spf record. Here's my setup:
>
>I have a colo server in a datacenter, which has a single ip address.

relavant

> I run several websites on this server, with multiple domains that each host a website. Email can be sent from any of these domains, via the local sendmail server, with 'neil' as the username and then the current website domain as the tld for the email address. So for example one of my sites is crazyguyonabike.com, so when I send a registration email from that site, it is 'From' neil@crazyguyonabike.com. The reverse DNS and mx for the ip address is spidey.nilspace.com.

irrelevant

ok assuming your sendmail greets [helo/ehlo] as spidey.nilspace.com.
first spf record should be for this domain (currently none)
as above it should only be for a helo/ehlo thus should terminate -all
v=spf1 ip4:208.64.24.170 -all

next neil@crazyguyonabike.com.
currently broken beyond belief
should be v=spf1 ip4:208.64.24.170 -/~/?all

-/~/? means pick one depending on the forgery handling policy you want receivers to follow

- means mail from any other ip should be considered spam/forged harshly HARDFAIL (breaks non-SRS forwarding to ISPs to sloppy to allow users to whitelist their own forwarders)
~ means to consider mail from any other ip to be probably spam (but not always) SOFTFAIL (survives more broken forwarding but also less strongly protects you from forgery)
? means consider mail that hasnt passed the spf test like you would mail with no SPF NEUTRAL (pointless but breaks less and forwarding and perfect for testing)

>I also send email through this server from my home computer, which is on a cable or DSL connection. When I do this, sendmail always seems to attach a "may be forged" header to my emails, and I can't seem to stop that from happening - presumably it's because my emails are "from" neil@nilspace.com, but my originating ip address does not resolve to nilspace.com, but rather to the cable or DSL company. This isn't the main issue, though.

pointless but nothing but sendmail being mis-configured
(you do send mail via an authenticated connection to port 587 (the mail submission port) I assume)
if so as long as sendmail trusts your ID/password it should trust your envelope-sender

>The problem is that I find that sometimes my emails just don't get through at all. In particular, I recently changed the registration confirmations on crazyguyonabike.com to be 'From' neil@crazyguyonabike.com, whereas previously they came 'From' neil@nilspace.com. I wanted the address to match the domain the person was registering on. However now I have had a couple of instances where these confirmations just aren't getting through at all, and this is to yahoo.com email accounts, which previously have been very reliable in terms of delivery. The messages aren't in the spam folder, they just never seem to get through at all. The weird thing is that emails from neil@nilspace.com, sent from my home computer, do get through. So the automated ones from the server don't get through, but ones from home do, but they are both coming from the same email server. I'm wondering if the spf record has something to do with it - maybe Yahoo! is seeing something weird about an email claiming
to be
from crazyguyonabike.com, but my spf doesn't mention that domain? Here's my current SPF record, generated a while back from an online wizard:

your and anyone spf is just a list of ip's nothing 'sees' the domains mentioned within
your spf having a broken second last record and ending +all is a more likely cause

and btw no one looks at the from address just the envelope-sender
its likely if your home mail is being treated differently it because either its envelope-sender is correct
(and thus the web-script is perhaps sending from:correct-address but leaving the envelope-sender as apache@spidey... or some other nonsense)

with sendmail its necessary to use -f and have the user running the process in trusted-users to allow 'forging/setting the envelope sender to anything but the default'

a copy of one of each type of mail with full headers will answer this faster than me trying to teach you how to distinguish between them

send one of each direct (not via list) to my address and I'll look at them in the morning, and tell you which is broken


>"v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>
>Should I have more stuff in there related to my other domains, even though they all resolve to the same IP address? How about my home connection, do I need to have anything related to that in there?
>
>Hope this makes sense, please let me know if you need more information...
>
>Thanks!
>
>Neil
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/15739084-a04d3caa
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101130204417:81179282-FCEC-11DF-97DB-AC9BBAB6F015
>Powered by Listbox: http://www.listbox.com



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101201050611:9EA524EA-FD32-11DF-8019-93DF6268812C
Powered by Listbox: http://www.listbox.com

Ok, thanks again. I have changed all my spf records for bind to the
following:

TXT "v=spf1 ip4:208.64.24.170 -all"
SPF "v=spf1 ip4:208.64.24.170 -all"

My setup is pretty simple - multiple domains on a single ip address, so
I guess that should do it, right? Thanks for the clarification of the
'all', the entry I had was generated (I think) from one of the spf
"wizards" online, possibly the Microsoft one, but I can't remember.
Obviously either I misunderstood the questions the wizard asked me, or
else the wizard itself was screwed up.

Also, what I am getting is that the ip address of my computer here at
home (which originates email sent personally by me) is irrelevant to spf
- the only ip address that matters is the address of my mail server, is
that correct? If so, then the above entries make perfect sense, since
they seem to say that mail can come from this ip address, and only this
ip address (true, I have no other email servers), and the '-all' says
exclude any other ip addresses. Sounds simple.

Sorry for my ignorance, I am very busy with development and did not take
the time to dedicate to learning about spf in depth, but you've been
extremely helpful. Much appreciated.

I think that should do it, please let me know if I'm missing anything
else here...

Thanks again,

Neil

alan wrote:
> ok questions dealt with in reverse order as its late and only the last approached an SPF issue
>
> first off your SPF
>
> "v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>
> utter bollix beyond useless and will get your mail dumped by any anti-spam system
>
> starting from the fact you send all mail from one ip (spidey.nilspace.com)
> should theirfore be
> "v=spf1 ip4:208.64.24.170
> then either ?all ~all or -all
>
> and that is all
> the a (waste of receivers resources as it will be the same ip
> the mx (waste of receivers resources as it will be the same ip
> the ptr (should never be used and will never match
> the mx:spidey.nilspace.com (error breaking all as spidey.nilspace.com has no MX records
> the +all (biggest mistake of all says "oh and we send from every ip in the world too" classic spammer and will get mail shot
>
> now onto the rest
>
> At 01:44 01/12/2010 Wednesday, Neil Gunton wrote:
>> Hi, I'm sorry if this turns out to be a stupid question, but I'm having some trouble working out how to construct my spf record. Here's my setup:
>>
>> I have a colo server in a datacenter, which has a single ip address.
>
> relavant
>
>> I run several websites on this server, with multiple domains that each host a website. Email can be sent from any of these domains, via the local sendmail server, with 'neil' as the username and then the current website domain as the tld for the email address. So for example one of my sites is crazyguyonabike.com, so when I send a registration email from that site, it is 'From' neil@crazyguyonabike.com. The reverse DNS and mx for the ip address is spidey.nilspace.com.
>
> irrelevant
>
> ok assuming your sendmail greets [helo/ehlo] as spidey.nilspace.com.
> first spf record should be for this domain (currently none)
> as above it should only be for a helo/ehlo thus should terminate -all
> v=spf1 ip4:208.64.24.170 -all
>
> next neil@crazyguyonabike.com.
> currently broken beyond belief
> should be v=spf1 ip4:208.64.24.170 -/~/?all
>
> -/~/? means pick one depending on the forgery handling policy you want receivers to follow
>
> - means mail from any other ip should be considered spam/forged harshly HARDFAIL (breaks non-SRS forwarding to ISPs to sloppy to allow users to whitelist their own forwarders)
> ~ means to consider mail from any other ip to be probably spam (but not always) SOFTFAIL (survives more broken forwarding but also less strongly protects you from forgery)
> ? means consider mail that hasnt passed the spf test like you would mail with no SPF NEUTRAL (pointless but breaks less and forwarding and perfect for testing)
>
>> I also send email through this server from my home computer, which is on a cable or DSL connection. When I do this, sendmail always seems to attach a "may be forged" header to my emails, and I can't seem to stop that from happening - presumably it's because my emails are "from" neil@nilspace.com, but my originating ip address does not resolve to nilspace.com, but rather to the cable or DSL company. This isn't the main issue, though.
>
> pointless but nothing but sendmail being mis-configured
> (you do send mail via an authenticated connection to port 587 (the mail submission port) I assume)
> if so as long as sendmail trusts your ID/password it should trust your envelope-sender
>
>> The problem is that I find that sometimes my emails just don't get through at all. In particular, I recently changed the registration confirmations on crazyguyonabike.com to be 'From' neil@crazyguyonabike.com, whereas previously they came 'From' neil@nilspace.com. I wanted the address to match the domain the person was registering on. However now I have had a couple of instances where these confirmations just aren't getting through at all, and this is to yahoo.com email accounts, which previously have been very reliable in terms of delivery. The messages aren't in the spam folder, they just never seem to get through at all. The weird thing is that emails from neil@nilspace.com, sent from my home computer, do get through. So the automated ones from the server don't get through, but ones from home do, but they are both coming from the same email server. I'm wondering if the spf record has something to do with it - maybe Yahoo! is seeing something weird about an email claimin
g
> to be
> from crazyguyonabike.com, but my spf doesn't mention that domain? Here's my current SPF record, generated a while back from an online wizard:
>
> your and anyone spf is just a list of ip's nothing 'sees' the domains mentioned within
> your spf having a broken second last record and ending +all is a more likely cause
>
> and btw no one looks at the from address just the envelope-sender
> its likely if your home mail is being treated differently it because either its envelope-sender is correct
> (and thus the web-script is perhaps sending from:correct-address but leaving the envelope-sender as apache@spidey... or some other nonsense)
>
> with sendmail its necessary to use -f and have the user running the process in trusted-users to allow 'forging/setting the envelope sender to anything but the default'
>
> a copy of one of each type of mail with full headers will answer this faster than me trying to teach you how to distinguish between them
>
> send one of each direct (not via list) to my address and I'll look at them in the morning, and tell you which is broken
>
>
>> "v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>>
>> Should I have more stuff in there related to my other domains, even though they all resolve to the same IP address? How about my home connection, do I need to have anything related to that in there?
>>
>> Hope this makes sense, please let me know if you need more information...
>>
>> Thanks!
>>
>> Neil
>>
>>
>> -------------------------------------------
>> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>> Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>
>> Archives: https://www.listbox.com/member/archive/1020/=now
>> RSS Feed: https://www.listbox.com/member/archive/rss/1020/15739084-a04d3caa
>> Modify Your Subscription: https://www.listbox.com/member/?&
>> Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101130204417:81179282-FCEC-11DF-97DB-AC9BBAB6F015
>> Powered by Listbox: http://www.listbox.com
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/1020/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/1020/19965496-c01dc913
> Modify Your Subscription: https://www.listbox.com/member/?&
> Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101201050611:9EA524EA-FD32-11DF-8019-93DF6268812C
> Powered by Listbox: http://www.listbox.com
>



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101201132807:C02A1ABC-FD78-11DF-A576-82368AEC8845
Powered by Listbox: http://www.listbox.com

Ho ricevuto il messaggio. Sono in ferie fino al 16 dicembre, legger� il messaggio al mio rientro il 17 dicembre.
Per cose urgenti potete scrivere a info@biatwork.com, i miei colleghi prenderanno in carico la vostra email.

Cordiali saluti
Massimo Gregori





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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101201132953:FC2A3394-FD78-11DF-B333-E17E85394F45
Powered by Listbox: http://www.listbox.com

At 18:27 01/12/2010 Wednesday, Neil Gunton wrote:
>Ok, thanks again. I have changed all my spf records for bind to the following:
>
>TXT "v=spf1 ip4:208.64.24.170 -all"
>SPF "v=spf1 ip4:208.64.24.170 -all"

again i urge you to consider ?all while testing
(as you cannot easily guess what forwarding arrangements your receivers may have and -all will cause all recievers with badly setup (non-whitelisted forwarding hosts) to reject all the (forged by their own forwarder) mail

>My setup is pretty simple - multiple domains on a single ip address, so I guess that should do it, right? Thanks for the clarification of the 'all', the entry I had was generated (I think) from one of the spf "wizards" online, possibly the Microsoft one,

the microsoft one is NOT spf (same syntax totally different system) called senderID, and not compatable

> but I can't remember. Obviously either I misunderstood the questions the wizard asked me, or else the wizard itself was screwed up.

usually the second no wizard i have seen approaches anything near to simple logic.

>Also, what I am getting is that the ip address of my computer here at home (which originates email sent personally by me) is irrelevant to spf -

yes

> the only ip address that matters is the address of my mail server, is that correct?

not entirely, not your mail server, but any mail server that is allowed to send mail to others on your behalf

{for example if your server was only used to receive and you used your isp 'isp-x' to send mail only, then your spf should have no mention of your server just the ip's/mames of the isp-x servers)

> If so, then the above entries make perfect sense, since they seem to say that mail can come from this ip address, and only this ip address (true, I have no other email servers), and the '-all' says exclude any other ip addresses. Sounds simple.

yup it is but..
- all means HARDFAIL all others (ie you recommend that they refuse mail from any other source)
~ all means SOFTFAIL all others (ie you recommend treating other sources with suspicion)
? all means NEUTRAL all others (ie you recommend treating other sources neither positively(pass) or negatively(fail) just treat them the way you do email with no spf)

as in my original mail

>Sorry for my ignorance, I am very busy with development and did not take the time to dedicate to learning about spf in depth, but you've been extremely helpful. Much appreciated.
>
>I think that should do it, please let me know if I'm missing anything else here...
>
>Thanks again,
>
>Neil
>
>alan wrote:
>>ok questions dealt with in reverse order as its late and only the last approached an SPF issue
>>first off your SPF
>>"v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>>utter bollix beyond useless and will get your mail dumped by any anti-spam system
>>starting from the fact you send all mail from one ip (spidey.nilspace.com)
>>should theirfore be
>>"v=spf1 ip4:208.64.24.170 then either ?all ~all or -all
>>and that is all
>>the a (waste of receivers resources as it will be the same ip
>>the mx (waste of receivers resources as it will be the same ip
>>the ptr (should never be used and will never match
>>the mx:spidey.nilspace.com (error breaking all as spidey.nilspace.com has no MX records
>>the +all (biggest mistake of all says "oh and we send from every ip in the world too" classic spammer and will get mail shot
>>now onto the rest
>>At 01:44 01/12/2010 Wednesday, Neil Gunton wrote:
>>>Hi, I'm sorry if this turns out to be a stupid question, but I'm having some trouble working out how to construct my spf record. Here's my setup:
>>>
>>>I have a colo server in a datacenter, which has a single ip address.
>>relavant
>>
>>>I run several websites on this server, with multiple domains that each host a website. Email can be sent from any of these domains, via the local sendmail server, with 'neil' as the username and then the current website domain as the tld for the email address. So for example one of my sites is crazyguyonabike.com, so when I send a registration email from that site, it is 'From' neil@crazyguyonabike.com. The reverse DNS and mx for the ip address is spidey.nilspace.com.
>>irrelevant
>>ok assuming your sendmail greets [helo/ehlo] as spidey.nilspace.com.
>>first spf record should be for this domain (currently none)
>>as above it should only be for a helo/ehlo thus should terminate -all
>>v=spf1 ip4:208.64.24.170 -all
>>next neil@crazyguyonabike.com.
>>currently broken beyond belief
>>should be v=spf1 ip4:208.64.24.170 -/~/?all
>>-/~/? means pick one depending on the forgery handling policy you want receivers to follow
>>- means mail from any other ip should be considered spam/forged harshly HARDFAIL (breaks non-SRS forwarding to ISPs to sloppy to allow users to whitelist their own forwarders)
>>~ means to consider mail from any other ip to be probably spam (but not always) SOFTFAIL (survives more broken forwarding but also less strongly protects you from forgery)
>>? means consider mail that hasnt passed the spf test like you would mail with no SPF NEUTRAL (pointless but breaks less and forwarding and perfect for testing)
>>
>>>I also send email through this server from my home computer, which is on a cable or DSL connection. When I do this, sendmail always seems to attach a "may be forged" header to my emails, and I can't seem to stop that from happening - presumably it's because my emails are "from" neil@nilspace.com, but my originating ip address does not resolve to nilspace.com, but rather to the cable or DSL company. This isn't the main issue, though.
>>pointless but nothing but sendmail being mis-configured
>>(you do send mail via an authenticated connection to port 587 (the mail submission port) I assume)
>>if so as long as sendmail trusts your ID/password it should trust your envelope-sender
>>
>>>The problem is that I find that sometimes my emails just don't get through at all. In particular, I recently changed the registration confirmations on crazyguyonabike.com to be 'From' neil@crazyguyonabike.com, whereas previously they came 'From' neil@nilspace.com. I wanted the address to match the domain the person was registering on. However now I have had a couple of instances where these confirmations just aren't getting through at all, and this is to yahoo.com email accounts, which previously have been very reliable in terms of delivery. The messages aren't in the spam folder, they just never seem to get through at all. The weird thing is that emails from neil@nilspace.com, sent from my home computer, do get through. So the automated ones from the server don't get through, but ones from home do, but they are both coming from the same email server. I'm wondering if the spf record has something to do with it - maybe Yahoo! is seeing something weird about an email claimin
>g
>> to be
>> from crazyguyonabike.com, but my spf doesn't mention that domain? Here's my current SPF record, generated a while back from an online wizard:
>>your and anyone spf is just a list of ip's nothing 'sees' the domains mentioned within
>>your spf having a broken second last record and ending +all is a more likely cause
>>and btw no one looks at the from address just the envelope-sender
>>its likely if your home mail is being treated differently it because either its envelope-sender is correct
>>(and thus the web-script is perhaps sending from:correct-address but leaving the envelope-sender as apache@spidey... or some other nonsense)
>>with sendmail its necessary to use -f and have the user running the process in trusted-users to allow 'forging/setting the envelope sender to anything but the default'
>>a copy of one of each type of mail with full headers will answer this faster than me trying to teach you how to distinguish between them
>>send one of each direct (not via list) to my address and I'll look at them in the morning, and tell you which is broken
>>
>>>"v=spf1 a mx ptr ip4:208.64.24.170 mx:spidey.nilspace.com +all"
>>>
>>>Should I have more stuff in there related to my other domains, even though they all resolve to the same IP address? How about my home connection, do I need to have anything related to that in there?
>>>
>>>Hope this makes sense, please let me know if you need more information...
>>>
>>>Thanks!
>>>
>>>Neil
>>>
>>>
>>>-------------------------------------------
>>>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>>>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>>
>>>Archives: https://www.listbox.com/member/archive/1020/=now
>>>RSS Feed: https://www.listbox.com/member/archive/rss/1020/15739084-a04d3caa
>>>Modify Your Subscription: https://www.listbox.com/member/?&
>>>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101130204417:81179282-FCEC-11DF-97DB-AC9BBAB6F015
>>>Powered by Listbox: http://www.listbox.com
>>
>>-------------------------------------------
>>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>>Archives: https://www.listbox.com/member/archive/1020/=now
>>RSS Feed: https://www.listbox.com/member/archive/rss/1020/19965496-c01dc913
>>Modify Your Subscription: https://www.listbox.com/member/?&
>>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101201050611:9EA524EA-FD32-11DF-8019-93DF6268812C
>>Powered by Listbox: http://www.listbox.com
>
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/15739084-a04d3caa
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101201132807:C02A1ABC-FD78-11DF-A576-82368AEC8845
>Powered by Listbox: http://www.listbox.com



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202055338:6CBD03BE-FE02-11DF-B9E9-C1D3C6ED1EB0
Powered by Listbox: http://www.listbox.com

Ho ricevuto il messaggio. Sono in ferie fino al 16 dicembre, legger� il messaggio al mio rientro il 17 dicembre.
Per cose urgenti potete scrivere a info@biatwork.com, i miei colleghi prenderanno in carico la vostra email.

Cordiali saluti
Massimo Gregori





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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202055610:C6B02B6C-FE02-11DF-913D-DFA34CCE0452
Powered by Listbox: http://www.listbox.com

alan wrote:
> At 18:27 01/12/2010 Wednesday, Neil Gunton wrote:
>> Ok, thanks again. I have changed all my spf records for bind to the following:
>>
>> TXT "v=spf1 ip4:208.64.24.170 -all"
>> SPF "v=spf1 ip4:208.64.24.170 -all"
>
> again i urge you to consider ?all while testing
> (as you cannot easily guess what forwarding arrangements your receivers may have and -all will cause all recievers with badly setup (non-whitelisted forwarding hosts) to reject all the (forged by their own forwarder) mail

Then I don't see when you would ever use -all, because with any public
email system you cannot predict in advance who you will be sending
messages to. You never have any idea what their forwarding setups are.
So why do you say "during testing"? When would this testing phase end,
exactly? How could it ever end, given the intrinsic uncertainty of who
you might have to send emails to in the future?

All I do know is that I definitely want to make it clear to the world
that email coming from me can only originate from my server.

> the microsoft one is NOT spf (same syntax totally different system) called senderID, and not compatable

Then their web page is extremely misleading, because they use "SPF" in
the title:

http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

Anybody (like myself) looking around on the web for SPF wizards to help
them construct one of these records might reasonably assume that "SPF is
SPF", and use this - the result looks identical to the official SPF to
me. This is really bad, especially as you're saying they are actually
incompatible.

>> but I can't remember. Obviously either I misunderstood the questions the wizard asked me, or else the wizard itself was screwed up.
>
> usually the second no wizard i have seen approaches anything near to simple logic.

Again, this is bad, most people will try to use the wizards rather than
spend their time learning the innards of yet another specification.

>> the only ip address that matters is the address of my mail server, is that correct?
>
> not entirely, not your mail server, but any mail server that is allowed to send mail to others on your behalf

The only server that is allowed to send emails to others as coming from
me or any of my website processes is my server. I don't know of any
situation where some other server is going to be sending emails to
others "on my behalf", isn't that just a recipe for spammers to send
email as "me"? It should never happen, as far as I know.

> {for example if your server was only used to receive and you used your isp 'isp-x' to send mail only, then your spf should have no mention of your server just the ip's/mames of the isp-x servers)

My email server is used to send and receive all my email.

> - all means HARDFAIL all others (ie you recommend that they refuse mail from any other source)
> ~ all means SOFTFAIL all others (ie you recommend treating other sources with suspicion)
> ? all means NEUTRAL all others (ie you recommend treating other sources neither positively(pass) or negatively(fail) just treat them the way you do email with no spf)

Given that all mail I send or receive goes from/to this one server,
isn't this about as solid a case as you could ever get for using -all?

Thanks again,

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202122620:490EFE04-FE39-11DF-8E6B-829DE8F8D026
Powered by Listbox: http://www.listbox.com

Hi Neil,

Neil Gunton wrote:
> Then I don't see when you would ever use -all, because with any public
> email system you cannot predict in advance who you will be sending
> messages to. You never have any idea what their forwarding setups are.
> So why do you say "during testing"? When would this testing phase end,
> exactly? How could it ever end, given the intrinsic uncertainty of who
> you might have to send emails to in the future?

You'd be testing who is sending mail, not receiving it. It's up to the
receivers to decide how to handle your mail and how to act upon your SPF
record. All you can do is make sure your record is correct.

> All I do know is that I definitely want to make it clear to the world
> that email coming from me can only originate from my server.

The the SPF record you mentioned in your last message should work fine.

>> the microsoft one is NOT spf (same syntax totally different system)
>> called senderID, and not compatable
>
> Then their web page is extremely misleading, because they use "SPF" in
> the title:
>
> http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

Yes it is.

> Anybody (like myself) looking around on the web for SPF wizards to help
> them construct one of these records might reasonably assume that "SPF is
> SPF", and use this - the result looks identical to the official SPF to
> me. This is really bad, especially as you're saying they are actually
> incompatible.

It's not that they're incompatible. If you only publish an SPF record,
Sender-ID will use that. However, the behaviour of Sender-ID is
different from that of SPF.

It is recommended, that if you do not intend for your SPF record to be
used by Sender-ID-aware hosts, that you also publish the following
Sender-ID record:

TXT "spf2.0/pra"

If, however, you wish to use Sender-ID, you should research it and
publish an appropriate record.

>>> but I can't remember. Obviously either I misunderstood the questions
>>> the wizard asked me, or else the wizard itself was screwed up.
>>
>> usually the second no wizard i have seen approaches anything near to
>> simple logic.
>
> Again, this is bad, most people will try to use the wizards rather than
> spend their time learning the innards of yet another specification.

Most SPF records can be generated by asking the simple question: "What
hosts are authorized to send mail for your domain?" Then list the IP
addresses of those hosts in your SPF record as you have done.

>>> the only ip address that matters is the address of my mail server, is
>>> that correct?
>>
>> not entirely, not your mail server, but any mail server that is
>> allowed to send mail to others on your behalf
>
> The only server that is allowed to send emails to others as coming from
> me or any of my website processes is my server. I don't know of any
> situation where some other server is going to be sending emails to
> others "on my behalf", isn't that just a recipe for spammers to send
> email as "me"? It should never happen, as far as I know.

If, for example, you hired a marketing company to send communications to
your customers. If they sent emails from their servers as you, one
option would be to add their servers to your SPF record. (There are
other, often better solutions for this.)

>> {for example if your server was only used to receive and you used your
>> isp 'isp-x' to send mail only, then your spf should have no mention of
>> your server just the ip's/mames of the isp-x servers)
>
> My email server is used to send and receive all my email.

Then the record you have is fine.

>
>> - all means HARDFAIL all others (ie you recommend that they refuse
>> mail from any other source)
>> ~ all means SOFTFAIL all others (ie you recommend treating other
>> sources with suspicion)
>> ? all means NEUTRAL all others (ie you recommend treating other
>> sources neither positively(pass) or negatively(fail) just treat them
>> the way you do email with no spf)
>
> Given that all mail I send or receive goes from/to this one server,
> isn't this about as solid a case as you could ever get for using -all?

Yes. Not all mail environments are as simple as yours. These options are
available to allow for increased/softer testing.

Andrew

>
> Thanks again,
>
> Neil
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/1020/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/1020/14525495-91eca367
> Modify Your Subscription:
> https://www.listbox.com/member/?&
>
> Unsubscribe Now:
> https://www.listbox.com/unsubscribe/?&&post_id=20101202122620:490EFE04-FE39-11DF-8E6B-829DE8F8D026
>
> Powered by Listbox: http://www.listbox.com


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202124906:73A3F7CA-FE3C-11DF-A52E-8F0DC6F4DBAC
Powered by Listbox: http://www.listbox.com

> Then I don't see when you would ever use -all

You use -all when you're sure you've got the config right. Are you sure
your config is right?

> Then their web page is extremely misleading

This is not news. Please complain to them - it was their decision to
attempt to subvert SPF.

> The only server that is allowed to send emails to others as coming from
> me or any of my website processes is my server. I don't know of any
> situation where some other server is going to be sending emails to
> others "on my behalf"

Mailing lists are the usual fare. They often send on mails with the
original envelope address; this is a forgery, but it is your email that
will suffer.

> isn't that just a recipe for spammers to send
> email as "me"? It should never happen, as far as I know.

That last phrase is the important one. That's why people have been
suggesting you do not use "-all" immediately.

> Given that all mail I send or receive goes from/to this one server,
> isn't this about as solid a case as you could ever get for using -all?

If you are sure that what you have told us is 100% accurate and complete,
then yes. If you have missed out anything or have any misunderstandings,
it could cause your mail to be undeliverable for as long as any DNS server
decides to cache your record - which is frequently longer than the TTL you
specify.

Do you not think it might be a good idea to take the advice not to use
"-all" just yet? I've been doing SPF for some years now, and I still make
mistakes, although clearly you might have a much better grasp of the
technology than I.

Vic.



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202124928:81758274-FE3C-11DF-93A8-D455F559ED1D
Powered by Listbox: http://www.listbox.com

Andrew Culver wrote:
> You'd be testing who is sending mail, not receiving it. It's up to the
> receivers to decide how to handle your mail and how to act upon your SPF
> record. All you can do is make sure your record is correct.

I have done some tests with sending to gmail accounts, and it does seem
to be working. Google lets you look at how they interpreted the SPF
record, and it looks good from their end.

>> All I do know is that I definitely want to make it clear to the world
>> that email coming from me can only originate from my server.
>
> The the SPF record you mentioned in your last message should work fine.

That's good, thanks.

> It's not that they're incompatible. If you only publish an SPF record,
> Sender-ID will use that. However, the behaviour of Sender-ID is
> different from that of SPF.

My main goal here is to ensure that my messages get delivered to the
people who attempt to use my website. It has seemed recently that I've
been getting more messages from people complaining that they never got
the confirmation email, even after looking in their spam folder etc. So
this prompted my quest to perfect the SPF record, and I'm really glad I
joined this list now, because apparently my previous attempt was
severely messed up.

> It is recommended, that if you do not intend for your SPF record to be
> used by Sender-ID-aware hosts, that you also publish the following
> Sender-ID record:
>
> TXT "spf2.0/pra"
>
> If, however, you wish to use Sender-ID, you should research it and
> publish an appropriate record.

Is there much benefit to going to that trouble? Will hosts that use
Sender-ID be able to see from my existing SPF record that the email is
genuine? They are so similar, I don't see why we need a different
standard. In fact the worst case is when it is "similar but different",
in my experience. Oh, sorry, I forgot we're talking about Microsoft
here. Carry on.

> Most SPF records can be generated by asking the simple question: "What
> hosts are authorized to send mail for your domain?" Then list the IP
> addresses of those hosts in your SPF record as you have done.

That's very simple and clear, thanks.

>> The only server that is allowed to send emails to others as coming
>> from me or any of my website processes is my server. I don't know of
>> any situation where some other server is going to be sending emails to
>> others "on my behalf", isn't that just a recipe for spammers to send
>> email as "me"? It should never happen, as far as I know.
>
> If, for example, you hired a marketing company to send communications to
> your customers. If they sent emails from their servers as you, one
> option would be to add their servers to your SPF record. (There are
> other, often better solutions for this.)

Yikes - that sounds like spam to me. But I do understand, thanks again.

>> My email server is used to send and receive all my email.
>
> Then the record you have is fine.

Good.

>> Given that all mail I send or receive goes from/to this one server,
>> isn't this about as solid a case as you could ever get for using -all?
>
> Yes. Not all mail environments are as simple as yours. These options are
> available to allow for increased/softer testing.

I appreciate that, thanks again for your patience.

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202130653:F005768E-FE3E-11DF-82B0-EB9763EF98E0
Powered by Listbox: http://www.listbox.com

Vic wrote:
> Do you not think it might be a good idea to take the advice not to use
> "-all" just yet? I've been doing SPF for some years now, and I still make
> mistakes, although clearly you might have a much better grasp of the
> technology than I.

I'm not trying to be argumentitive here, but from what I gather my setup
really is very simple. I only send and receive email from the one,
single server. I don't run any mailing lists, nobody else sends emails
on my behalf. I have tested the new SPF record with Yahoo! and Gmail,
and it passes. Since I fixed the previous broken config (thanks
Microsoft) I haven't had any problems with people registering.

Thanks again to everybody, this has been very useful, I'm most
appreciative of all the replies.

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202131118:9A7F7F24-FE3F-11DF-88CA-DA3EE12E9BCF
Powered by Listbox: http://www.listbox.com

> I'm not trying to be argumentitive here, but from what I gather my setup
> really is very simple.

You have been advised - properly, IMO - to run a "testing" record before
jumping in feet-first and implementing a policy that could conceivably
result in your email being undeliverable for multiple days. It is entirely
up to you whether or not to take that advice. The rest of us don't care -
it's not *our* mail you're risking.

> I don't run any mailing lists

Do you use any mailing lists? Do any of them forge your envelope address?
Do you use any non-conformant mail subscriptions (like PayPal, for
example)?

It is a trivial matter to tighten up your policy at a later date. I am
astounded that you are so loath to test something before you commit to it
- but it's your mail, so go ahead.

> nobody else sends emails on my behalf.

Do you know that for certain, or are you just asserting what you would
like to be the case?

Vic.



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202132556:A5E1D716-FE41-11DF-8E33-FAE89D581F39
Powered by Listbox: http://www.listbox.com

Hi,

Let me please join your conversation in the "asking" part of it.

Andrew, you introduce an interesting question to me:

*"If, for example, you hired a marketing company to send communications to
your customers. If they sent emails from their servers as you, one option
would be to add their servers to your SPF record. (There are other, often
better solutions for this.)"*


Recently, I've recommended a client of us (we are a small web agency
offering e-mail marketing solutions) to add our server's ip4 to their SPF
record.

Could you suggest a better solution for that case? They send mail to a
legitimate list of their customers and interested people, no spamming. They
send mail from the servers behind their domain, and we send mail on their
behalf from a server we manage.

We are completely open to any comment that may help mail filters and
handlers correctly qualify our messages.

Regards,

Marc Olivé i Valls
El Nucli
________________________________________________________________________________

Marc Olivé i Valls | marc@elnucli.com | www.elnucli.com

El Nucli és al Facebook
<http://www.facebook.com/pages/Manresa-Spain/El-Nucli/128809810270> | A
vegades fem tweets! <http://twitter.com/elnucli>

El Nucli 9-08, S.L. | Avinguda de les Bases de Manresa 52-58 1er 3a | 08242
• Manresa
tel: 937.013.260 | fax: 937.013.011

(Abans d'imprimir aquest correu penseu en el vostre compromís amb el medi
ambient)
On Thu, Dec 2, 2010 at 6:48 PM, Andrew Culver <aculver@uwo.ca> wrote:

> Hi Neil,
>
>
> Neil Gunton wrote:
>
>> Then I don't see when you would ever use -all, because with any public
>> email system you cannot predict in advance who you will be sending messages
>> to. You never have any idea what their forwarding setups are. So why do you
>> say "during testing"? When would this testing phase end, exactly? How could
>> it ever end, given the intrinsic uncertainty of who you might have to send
>> emails to in the future?
>>
>
> You'd be testing who is sending mail, not receiving it. It's up to the
> receivers to decide how to handle your mail and how to act upon your SPF
> record. All you can do is make sure your record is correct.
>
>
> All I do know is that I definitely want to make it clear to the world that
>> email coming from me can only originate from my server.
>>
>
> The the SPF record you mentioned in your last message should work fine.
>
>
> the microsoft one is NOT spf (same syntax totally different system) called
>>> senderID, and not compatable
>>>
>>
>> Then their web page is extremely misleading, because they use "SPF" in the
>> title:
>>
>>
>> http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
>>
>
> Yes it is.
>
>
> Anybody (like myself) looking around on the web for SPF wizards to help
>> them construct one of these records might reasonably assume that "SPF is
>> SPF", and use this - the result looks identical to the official SPF to me.
>> This is really bad, especially as you're saying they are actually
>> incompatible.
>>
>
> It's not that they're incompatible. If you only publish an SPF record,
> Sender-ID will use that. However, the behaviour of Sender-ID is different
> from that of SPF.
>
> It is recommended, that if you do not intend for your SPF record to be used
> by Sender-ID-aware hosts, that you also publish the following Sender-ID
> record:
>
> TXT "spf2.0/pra"
>
> If, however, you wish to use Sender-ID, you should research it and publish
> an appropriate record.
>
>
> but I can't remember. Obviously either I misunderstood the questions the
>>>> wizard asked me, or else the wizard itself was screwed up.
>>>>
>>>
>>> usually the second no wizard i have seen approaches anything near to
>>> simple logic.
>>>
>>
>> Again, this is bad, most people will try to use the wizards rather than
>> spend their time learning the innards of yet another specification.
>>
>
> Most SPF records can be generated by asking the simple question: "What
> hosts are authorized to send mail for your domain?" Then list the IP
> addresses of those hosts in your SPF record as you have done.
>
>
> the only ip address that matters is the address of my mail server, is that
>>>> correct?
>>>>
>>>
>>> not entirely, not your mail server, but any mail server that is allowed
>>> to send mail to others on your behalf
>>>
>>
>> The only server that is allowed to send emails to others as coming from me
>> or any of my website processes is my server. I don't know of any situation
>> where some other server is going to be sending emails to others "on my
>> behalf", isn't that just a recipe for spammers to send email as "me"? It
>> should never happen, as far as I know.
>>
>
> If, for example, you hired a marketing company to send communications to
> your customers. If they sent emails from their servers as you, one option
> would be to add their servers to your SPF record. (There are other, often
> better solutions for this.)
>
>
> {for example if your server was only used to receive and you used your isp
>>> 'isp-x' to send mail only, then your spf should have no mention of your
>>> server just the ip's/mames of the isp-x servers)
>>>
>>
>> My email server is used to send and receive all my email.
>>
>
> Then the record you have is fine.
>
>
>
>> - all means HARDFAIL all others (ie you recommend that they refuse mail
>>> from any other source)
>>> ~ all means SOFTFAIL all others (ie you recommend treating other sources
>>> with suspicion)
>>> ? all means NEUTRAL all others (ie you recommend treating other sources
>>> neither positively(pass) or negatively(fail) just treat them the way you do
>>> email with no spf)
>>>
>>
>> Given that all mail I send or receive goes from/to this one server, isn't
>> this about as solid a case as you could ever get for using -all?
>>
>
> Yes. Not all mail environments are as simple as yours. These options are
> available to allow for increased/softer testing.
>
> Andrew
>
>
>> Thanks again,
>>
>> Neil
>>
>>
>> -------------------------------------------
>> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>> Modify Your Subscription: http://www.listbox.com/member/ [
>> http://www.listbox.com/member/]
>>
>> Archives: https://www.listbox.com/member/archive/1020/=now
>> RSS Feed:
>> https://www.listbox.com/member/archive/rss/1020/14525495-91eca367
>> Modify Your Subscription: https://www.listbox.com/member/?&
>> Unsubscribe Now:
>> https://www.listbox.com/unsubscribe/?&&post_id=20101202122620:490EFE04-FE39-11DF-8E6B-829DE8F8D026
>> Powered by Listbox: http://www.listbox.com
>>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/ [
> http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/1020/=now
> RSS Feed:
> https://www.listbox.com/member/archive/rss/1020/20135140-294d0708
> Modify Your Subscription:
> https://www.listbox.com/member/?&
> Unsubscribe Now:
> https://www.listbox.com/unsubscribe/?&&post_id=20101202124906:73A3F7CA-FE3C-11DF-A52E-8F0DC6F4DBAC
>
> Powered by Listbox: http://www.listbox.com
>



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202132950:2F1EAD2E-FE42-11DF-902B-E392F559ED1D
Powered by Listbox: http://www.listbox.com

Vic wrote:
> Do you use any mailing lists? Do any of them forge your envelope address?
> Do you use any non-conformant mail subscriptions (like PayPal, for
> example)?

That's an excellent point. Paypal does send emails as being "from" its
users, doesn't it. And I do use mailing lists.

Ok, you've convinced me. I'll try '?all' instead of '-all' and see how
providers like Google and Yahoo! treat it. Of course I'll wait until the
TTL period expires (and more) to be sure.

Thanks again,

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202133236:8816EDD8-FE42-11DF-B893-9E90F5628087
Powered by Listbox: http://www.listbox.com

alan wrote:
> - all means HARDFAIL all others (ie you recommend that they refuse mail from any other source)
> ~ all means SOFTFAIL all others (ie you recommend treating other sources with suspicion)
> ? all means NEUTRAL all others (ie you recommend treating other sources neither positively(pass) or negatively(fail) just treat them the way you do email with no spf)

Ok, Vic raised excellent points in his previous email about me being
part of mailing lists (ironically, including this one) and also Paypal,
who sends out emails (I think) as being "from" me. I do use paypal on my
site for incoming donations, and I do on occasion paypal other people
money, so that might be very relevant.

Accordingly, I have changed to ?all now, as recommended for testing.

The next question is, let's say everything seems to be working fine, at
what point would I change this to ~all? Or is ?all a good way to leave
it long term?

Would ?all make some email providers treat emails coming from me with
any more suspicion than usual, since it is apparently more open to being
spoofed? I know it recommends neither positive or negative, but I'm just
wondering if some of the more aggressive email filters out there might
have a "presumed guilty" policy for more open SPF records.

Thanks again,

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202134308:03B75F08-FE44-11DF-8F2A-ACC28FC971C9
Powered by Listbox: http://www.listbox.com

Hi Marc,

The solution of having each of your clients add your mail servers (or
preferably include your SPF record) into their SPF record will work, but
you're adding extra work for each of your clients.

What we have done (uwo.ca) is instead asked any outside mailers wanting
to send mail as fundraiser@uwo.ca to change their SMTP MAIL FROM address
to their own domain and use fundraiser@uwo.ca in the From: header.

The From: header is what appears in the mail client. The user reading
the email doesn't really care what the SMTP MAIL FROM is. SPF cares
about the SMTP MAIL FROM, not the From: header.

This problem and the solution is described here:
http://www.openspf.org/Best_Practices/Webgenerated

Case 1)
MAIL FROM: fundraiser@uwo.ca
...
From: fundraiser@uwo.ca
To: user@uwo.ca

This will fail SPF. Bounces will be sent to fundraider@uwo.ca.

For this to work, the uwo.ca SPF record needs to be modified. The user
fundraiser@uwo.ca may also be receive bounces which they may not want to
see.


Case 2)
MAIL FROM: bounces@marketingcompany.com
...
From: fundraiser@uwo.ca
To: user@uwo.ca

This will pass SPF (assuming marketingcompany.com's SPF record is in
order). Bounces will be sent to bounces@marketingcompany.com (which
would allow the sender of the mail to better track bounces). The
recipient of this mail sees that the message was sent from
fundraiser@uwo.ca in their mail client.

This eliminates the need for your clients to modify their SPF. The
appearance of the email is maintained. You (as the mailer) can better
track bounces and eliminate non-existent mailboxes.


We've found this most effective and once the mailer has corrected their
SMTP MAIL FROM, there are never any more problems. Also, once the mailer
has made this change, it will work for ALL of their clients, eliminating
all SPF issues they would have had by using their clients domain.

Andrew



Marc Olivé wrote:
> Hi,
>
> Let me please join your conversation in the "asking" part of it.
>
> Andrew, you introduce an interesting question to me:
>
> /"If, for example, you hired a marketing company to send
> communications to your customers. If they sent emails from their
> servers as you, one option would be to add their servers to your SPF
> record. (There are other, often better solutions for this.)"/
>
>
> Recently, I've recommended a client of us (we are a small web agency
> offering e-mail marketing solutions) to add our server's ip4 to their
> SPF record.
>
> Could you suggest a better solution for that case? They send mail to a
> legitimate list of their customers and interested people, no spamming.
> They send mail from the servers behind their domain, and we send mail on
> their behalf from a server we manage.
>
> We are completely open to any comment that may help mail filters and
> handlers correctly qualify our messages.
>
> Regards,
>
> Marc Olivé i Valls
> El Nucli
> ________________________________________________________________________________
>
> Marc Olivé i Valls | marc@elnucli.com <mailto:marc@elnucli.com> |
> www.elnucli.com <http://www.elnucli.com>
>
> El Nucli és al Facebook
> <http://www.facebook.com/pages/Manresa-Spain/El-Nucli/128809810270> | A
> vegades fem tweets! <http://twitter.com/elnucli>
>
> El Nucli 9-08, S.L. | Avinguda de les Bases de Manresa 52-58 1er 3a |
> 08242 • Manresa
> tel: 937.013.260 | fax: 937.013.011
>
> (Abans d'imprimir aquest correu penseu en el vostre compromís amb el
> medi ambient)
> On Thu, Dec 2, 2010 at 6:48 PM, Andrew Culver <aculver@uwo.ca
> <mailto:aculver@uwo.ca>> wrote:
>
> Hi Neil,
>
>
> Neil Gunton wrote:
>
> Then I don't see when you would ever use -all, because with any
> public email system you cannot predict in advance who you will
> be sending messages to. You never have any idea what their
> forwarding setups are. So why do you say "during testing"? When
> would this testing phase end, exactly? How could it ever end,
> given the intrinsic uncertainty of who you might have to send
> emails to in the future?
>
>
> You'd be testing who is sending mail, not receiving it. It's up to
> the receivers to decide how to handle your mail and how to act upon
> your SPF record. All you can do is make sure your record is correct.
>
>
> All I do know is that I definitely want to make it clear to the
> world that email coming from me can only originate from my server.
>
>
> The the SPF record you mentioned in your last message should work fine.
>
>
> the microsoft one is NOT spf (same syntax totally different
> system) called senderID, and not compatable
>
>
> Then their web page is extremely misleading, because they use
> "SPF" in the title:
>
> http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
>
>
>
> Yes it is.
>
>
> Anybody (like myself) looking around on the web for SPF wizards
> to help them construct one of these records might reasonably
> assume that "SPF is SPF", and use this - the result looks
> identical to the official SPF to me. This is really bad,
> especially as you're saying they are actually incompatible.
>
>
> It's not that they're incompatible. If you only publish an SPF
> record, Sender-ID will use that. However, the behaviour of Sender-ID
> is different from that of SPF.
>
> It is recommended, that if you do not intend for your SPF record to
> be used by Sender-ID-aware hosts, that you also publish the
> following Sender-ID record:
>
> TXT "spf2.0/pra"
>
> If, however, you wish to use Sender-ID, you should research it and
> publish an appropriate record.
>
>
> but I can't remember. Obviously either I misunderstood
> the questions the wizard asked me, or else the wizard
> itself was screwed up.
>
>
> usually the second no wizard i have seen approaches anything
> near to simple logic.
>
>
> Again, this is bad, most people will try to use the wizards
> rather than spend their time learning the innards of yet another
> specification.
>
>
> Most SPF records can be generated by asking the simple question:
> "What hosts are authorized to send mail for your domain?" Then list
> the IP addresses of those hosts in your SPF record as you have done.
>
>
> the only ip address that matters is the address of my
> mail server, is that correct?
>
>
> not entirely, not your mail server, but any mail server that
> is allowed to send mail to others on your behalf
>
>
> The only server that is allowed to send emails to others as
> coming from me or any of my website processes is my server. I
> don't know of any situation where some other server is going to
> be sending emails to others "on my behalf", isn't that just a
> recipe for spammers to send email as "me"? It should never
> happen, as far as I know.
>
>
> If, for example, you hired a marketing company to send
> communications to your customers. If they sent emails from their
> servers as you, one option would be to add their servers to your SPF
> record. (There are other, often better solutions for this.)
>
>
> {for example if your server was only used to receive and you
> used your isp 'isp-x' to send mail only, then your spf
> should have no mention of your server just the ip's/mames of
> the isp-x servers)
>
>
> My email server is used to send and receive all my email.
>
>
> Then the record you have is fine.
>
>
>
> - all means HARDFAIL all others (ie you recommend that they
> refuse mail from any other source)
> ~ all means SOFTFAIL all others (ie you recommend treating
> other sources with suspicion)
> ? all means NEUTRAL all others (ie you recommend treating
> other sources neither positively(pass) or negatively(fail)
> just treat them the way you do email with no spf)
>
>
> Given that all mail I send or receive goes from/to this one
> server, isn't this about as solid a case as you could ever get
> for using -all?
>
>
> Yes. Not all mail environments are as simple as yours. These options
> are available to allow for increased/softer testing.
>
> Andrew
>
>
> Thanks again,
>
> Neil
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org
> [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/1020/=now
> RSS Feed:
> https://www.listbox.com/member/archive/rss/1020/14525495-91eca367
> Modify Your Subscription: https://www.listbox.com/member/?&
> <https://www.listbox.com/member/?&>
> Unsubscribe Now:
> https://www.listbox.com/unsubscribe/?&&post_id=20101202122620:490EFE04-FE39-11DF-8E6B-829DE8F8D026
> <https://www.listbox.com/unsubscribe/?&&post_id=20101202122620:490EFE04-FE39-11DF-8E6B-829DE8F8D026>
>
> Powered by Listbox: http://www.listbox.com
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/1020/=now
> RSS Feed:
> https://www.listbox.com/member/archive/rss/1020/20135140-294d0708
> Modify Your Subscription: https://www.listbox.com/member/?&
> <https://www.listbox.com/member/?&>
> Unsubscribe Now:
> https://www.listbox.com/unsubscribe/?&&post_id=20101202124906:73A3F7CA-FE3C-11DF-A52E-8F0DC6F4DBAC
> <https://www.listbox.com/unsubscribe/?&&post_id=20101202124906:73A3F7CA-FE3C-11DF-A52E-8F0DC6F4DBAC>
>
> Powered by Listbox: http://www.listbox.com
>
>
> Sender Policy Framework: http://www.openspf.org
> Modify Your Subscription: http://www.listbox.com/member/
>
> Archives <https://www.listbox.com/member/archive/1020/=now>
> <https://www.listbox.com/member/archive/rss/1020/14525495-91eca367> |
> Modify
> <https://www.listbox.com/member/?&>
> Your Subscription | Unsubscribe Now
> <https://www.listbox.com/unsubscribe/?&&post_id=20101202132950:2F1EAD2E-FE42-11DF-902B-E392F559ED1D>
> [Powered by Listbox] <http://www.listbox.com>
>


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202141810:E59F8DE2-FE48-11DF-B6DC-FCFF39F14A24
Powered by Listbox: http://www.listbox.com

Ho ricevuto il messaggio. Sono in ferie fino al 16 dicembre, legger� il messaggio al mio rientro il 17 dicembre.
Per cose urgenti potete scrivere a info@biatwork.com, i miei colleghi prenderanno in carico la vostra email.

Cordiali saluti
Massimo Gregori





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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202141926:09CB45A8-FE49-11DF-9344-BCC4E93F6B67
Powered by Listbox: http://www.listbox.com

Does it? Look at the Return-path: header to see the SMTP MAIL FROM
address that they used. SPF looks at this, not the From: header which
your mail client displays.

Another problem you may run into is forwarding by other hosts. Suppose
user@yourhost sends mail to user@forwarder who then forwards to
user@target. If the @target mail server is doing SPF checking and the
@forwarder mail server is not performing address rewriting (SRS), then
the @target mail server will see mail coming from the @forwarding mail
server with @yourhost in the SMTP MAIL FROM. This is a problem of the
forwarder (to implement SRS) or the target (to whitelist the
forwarder)... but users may complain to you all the same. This is where
testing with ~all can be useful.

Andrew

Neil Gunton wrote:
> Vic wrote:
>> Do you use any mailing lists? Do any of them forge your envelope address?
>> Do you use any non-conformant mail subscriptions (like PayPal, for
>> example)?
>
> That's an excellent point. Paypal does send emails as being "from" its
> users, doesn't it. And I do use mailing lists.
>
> Ok, you've convinced me. I'll try '?all' instead of '-all' and see how
> providers like Google and Yahoo! treat it. Of course I'll wait until the
> TTL period expires (and more) to be sure.
>
> Thanks again,
>
> Neil
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/1020/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/1020/14525495-91eca367
> Modify Your Subscription:
> https://www.listbox.com/member/?&
>
> Unsubscribe Now:
> https://www.listbox.com/unsubscribe/?&&post_id=20101202133236:8816EDD8-FE42-11DF-B893-9E90F5628087
>
> Powered by Listbox: http://www.listbox.com


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202142447:D4FF1E16-FE49-11DF-AB41-B37135ED268F
Powered by Listbox: http://www.listbox.com

Neil Gunton wrote:
>> It is recommended, that if you do not intend for your SPF record to be
>> used by Sender-ID-aware hosts, that you also publish the following
>> Sender-ID record:
>>
>> TXT "spf2.0/pra"
>>
>> If, however, you wish to use Sender-ID, you should research it and
>> publish an appropriate record.
>
> Is there much benefit to going to that trouble? Will hosts that use
> Sender-ID be able to see from my existing SPF record that the email is
> genuine? They are so similar, I don't see why we need a different
> standard. In fact the worst case is when it is "similar but different",
> in my experience. Oh, sorry, I forgot we're talking about Microsoft
> here. Carry on.

SPF acts on the SMTP MAIL FROM address (and sometimes the HELO address).

Sender-ID goes beyond this and tries to figure out what the Purported
Responsible Address (PRA) of the sender is and then check the Sender-ID
record of that address's domain. Sounds good in theory, however this is
easily fooled and so essentially useless.

What's worse, is Sender-ID implementations will use the SPF record if no
Sender-ID record exists. Although Sender-ID adoption is much less an
SPF, it can still cause delivery problems to those hosts that use it if
the sending domain lacks correct records, which is why the "spf2.0/pra"
record is recommended to prevent this fall-back.

Confused yet? :/



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202143206:D754438E-FE4A-11DF-82D5-5CCFC5F4DBAC
Powered by Listbox: http://www.listbox.com

Andrew Culver wrote:
> Does it? Look at the Return-path: header to see the SMTP MAIL FROM
> address that they used. SPF looks at this, not the From: header which
> your mail client displays.

Ok, for example I have an email from paypal which is a notification of a
payment to me. It is "From" the person who sent the payment, but the
Return-path header is payment@paypal.com. So if I sent someone a payment
via paypal, and my SPF has either ~all or -all, how would one or the
other affect the recipient getting the ensuing notification email from
paypal, assuming the recipient's email provider checks SPF?

> Another problem you may run into is forwarding by other hosts. Suppose
> user@yourhost sends mail to user@forwarder who then forwards to
> user@target. If the @target mail server is doing SPF checking and the
> @forwarder mail server is not performing address rewriting (SRS), then
> the @target mail server will see mail coming from the @forwarding mail
> server with @yourhost in the SMTP MAIL FROM. This is a problem of the
> forwarder (to implement SRS) or the target (to whitelist the
> forwarder)... but users may complain to you all the same. This is where
> testing with ~all can be useful.

Ok, so I'm not sure where that leaves me with regard to what to put in
my SPF record, since obviously (well, presumably, since you brought it
up) this scenario could happen any time, with any of my users. So what
to do?

Sorry, this just seems a bit confusing because people are telling me to
"test", but I can't predict what situations or people I will be dealing
with in the future.

I can already tell that, narrowly speaking for my own simple case of
dealing with sending emails to gmail and Yahoo!, that even -all works
fine. But I don't know how you test for all possible (unknown) future
situations to determine which form to use for all, like that forwarder
scenario above, or mailing lists or whatever.

Any advice on how to do this?

Thanks,

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202151028:3528C9C6-FE50-11DF-AC05-BE75F559ED1D
Powered by Listbox: http://www.listbox.com

Neil Gunton wrote:
> Andrew Culver wrote:
>> Does it? Look at the Return-path: header to see the SMTP MAIL FROM
>> address that they used. SPF looks at this, not the From: header which
>> your mail client displays.
>
> Ok, for example I have an email from paypal which is a notification of a
> payment to me. It is "From" the person who sent the payment, but the
> Return-path header is payment@paypal.com. So if I sent someone a payment
> via paypal, and my SPF has either ~all or -all, how would one or the
> other affect the recipient getting the ensuing notification email from
> paypal, assuming the recipient's email provider checks SPF?

The Return-path header is indicating what the SMTP MAIL FROM address
was. This is what SPF recipients look at. In this case, receivers would
look at the SPF record of paypal.com, not your domain. Paypal is doing
it right. (See Marc's thread for how someone in Paypal's situation could
do things wrong.)

>> Another problem you may run into is forwarding by other hosts. Suppose
>> user@yourhost sends mail to user@forwarder who then forwards to
>> user@target. If the @target mail server is doing SPF checking and the
>> @forwarder mail server is not performing address rewriting (SRS), then
>> the @target mail server will see mail coming from the @forwarding mail
>> server with @yourhost in the SMTP MAIL FROM. This is a problem of the
>> forwarder (to implement SRS) or the target (to whitelist the
>> forwarder)... but users may complain to you all the same. This is
>> where testing with ~all can be useful.
>
> Ok, so I'm not sure where that leaves me with regard to what to put in
> my SPF record, since obviously (well, presumably, since you brought it
> up) this scenario could happen any time, with any of my users. So what
> to do?
>
> Sorry, this just seems a bit confusing because people are telling me to
> "test", but I can't predict what situations or people I will be dealing
> with in the future.
>
> I can already tell that, narrowly speaking for my own simple case of
> dealing with sending emails to gmail and Yahoo!, that even -all works
> fine. But I don't know how you test for all possible (unknown) future
> situations to determine which form to use for all, like that forwarder
> scenario above, or mailing lists or whatever.
>
> Any advice on how to do this?

In the case of forwarders and mailing lists, this likely wouldn't change
your SPF record if you ran into problems. The problem would be with the
forwarder or mailing list operators to fix, since it's their problem.

Using ?all for a few weeks may help to identify these cases. By using
?all, messages may end up in a user's Spam folder rather than being
rejected. At least the recipient would still get the message and
hopefully alert you of the problem. You could then correct it or contact
the person responsible for correcting the problem before switching to -all.

You could also just set a low TTL (5 minutes) on your SPF record and set
it to -all. If you see any bounces that you don't expect, you can back
out with minimal impact. Don't forget to up the TTL when you're done
testing.

Andrew


> Thanks,
>
> Neil
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/1020/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/1020/14525495-91eca367
> Modify Your Subscription:
> https://www.listbox.com/member/?&
>
> Unsubscribe Now:
> https://www.listbox.com/unsubscribe/?&&post_id=20101202151028:3528C9C6-FE50-11DF-AC05-BE75F559ED1D
>
> Powered by Listbox: http://www.listbox.com


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202152037:96515B86-FE51-11DF-B875-D5295E46B21E
Powered by Listbox: http://www.listbox.com

> Does it?

Yes :-(

PayPal has a number of ways of sending email. Their subscription payment
system tends to forge the address of the recipient as the envelope from
address. I told them about this, and they ignored me.

Vic.



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202154244:BFDE43DA-FE54-11DF-8335-7785F559ED1D
Powered by Listbox: http://www.listbox.com

Andrew Culver wrote:
> The Return-path header is indicating what the SMTP MAIL FROM address
> was. This is what SPF recipients look at. In this case, receivers would
> look at the SPF record of paypal.com, not your domain. Paypal is doing
> it right. (See Marc's thread for how someone in Paypal's situation could
> do things wrong.)

> In the case of forwarders and mailing lists, this likely wouldn't change
> your SPF record if you ran into problems. The problem would be with the
> forwarder or mailing list operators to fix, since it's their problem.

I was just going by Vic's comment "Do you use any mailing lists? Do any
of them forge your envelope address? Do you use any non-conformant mail
subscriptions (like PayPal, for example)?" - this makes it sound like if
I use '-all' then Paypal and mailing lists will be messed up. But from
what you're saying, Paypal seems to be doing it right, and most mailing
lists are probably doing it right. So, still kind of confused. Some
people are telling me to be very afraid of some unspecified problem,
which I can't test for since I have no idea what systems I may encounter
down the road. Just trying it out for a week or a month isn't really a
valid test, since I have no idea if something new will pop up a week
after that.

> Using ?all for a few weeks may help to identify these cases. By using
> ?all, messages may end up in a user's Spam folder rather than being
> rejected.

Ok, but how would I then diagnose that SPF was the cause of the message
being shunted to the spam folder? If the recipient forwards it back to
me, will there necessarily be some headers or other information in there
indicating what happened, and why?

I have had a suspicion that spammers previously used the ip address
block in the datacenter where my server is colocated. The address itself
is not on any of the major block lists, but for a while providers like
comcast and gmail would consistently and mysteriously shunt my messages
to the spam folder, or even bounce them altogether. There was seldom, if
ever, any explanation about why this happened. That was what spurred my
whole foray into making SPF records, as an effort to try to make my
emails more legitimate to these increasingly over zealous spam filters.

> At least the recipient would still get the message and
> hopefully alert you of the problem. You could then correct it or contact
> the person responsible for correcting the problem before switching to -all.
>
> You could also just set a low TTL (5 minutes) on your SPF record and set
> it to -all. If you see any bounces that you don't expect, you can back
> out with minimal impact. Don't forget to up the TTL when you're done
> testing.

Ok, that sounds reasonable, I think I'll try that one. So that means
setting $TTL 300 in the bind configs for each domain, right? If I
haven't seen any big problems after a few weeks, then up it again to
86400. As long as I'm paying attention, I think I should be able to spot
any situations where emails are not getting through suddenly.

Thanks again for the advice, this has been very useful.

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202154337:E19B0C38-FE54-11DF-AE87-B2CA21EA18C8
Powered by Listbox: http://www.listbox.com

> You could also just set a low TTL (5 minutes) on your SPF record and set
> it to -all.

Bear in mind that some DNS servers - particularly those belonging to
cheapo ISPs, it seems - completely ignore short TTLs. You set it to an
hour, they use 2 days...

Vic.



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202154535:1D3E74B4-FE55-11DF-804D-009BF559ED1D
Powered by Listbox: http://www.listbox.com

Vic wrote:
> PayPal has a number of ways of sending email. Their subscription payment
> system tends to forge the address of the recipient as the envelope from
> address. I told them about this, and they ignored me.

...

> Bear in mind that some DNS servers - particularly those belonging to
> cheapo ISPs, it seems - completely ignore short TTLs. You set it to an
> hour, they use 2 days...

Ok, now I'm depressed.


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202155418:4A6C5BE4-FE56-11DF-98F4-8FB92BC2231B
Powered by Listbox: http://www.listbox.com

>> In the case of forwarders and mailing lists, this likely wouldn't change
>> your SPF record if you ran into problems. The problem would be with the
>> forwarder or mailing list operators to fix, since it's their problem.

I disagree with this comment.

Although the fault might be in the forwarding software that does things
wrong, that's not where the blame ends up. If you make a change and
something breaks, many people have a real problem taking the message that
it's their fault, not yours.

> this makes it sound like if
> I use '-all' then Paypal and mailing lists will be messed up.

No - it means that they *might* be messed up. If you roll out SPF
cautiously, you can identify any such breakage without too much
inconvenience. Or you can just stick in a "-all" and try your hand. I
don't care.

> But from what you're saying, Paypal seems to be doing it right

PayPal are one of the worst offenders for forging envelope addresses - but
not on all of their services. Having one that works doesn't mean that they
all will.

> and most mailing lists are probably doing it right.

And many are doing it wrong.

> Some
> people are telling me to be very afraid of some unspecified problem,

No-one is saying any such thing.

All you've been told is that it's a good idea to roll out cautiously, and
do some testing before getting into a situation that might cause problems.
But this is your choice.

> I have had a suspicion that spammers previously used the ip address
> block in the datacenter where my server is colocated.

SPF is unlikely to make any difference to that situation whatsoever.

> That was what spurred my
> whole foray into making SPF records, as an effort to try to make my
> emails more legitimate to these increasingly over zealous spam filters.

Remember that SPF is ***NOT*** and anti-spam measure; it's an anti-forgery
measure.

> Ok, that sounds reasonable, I think I'll try that one. So that means
> setting $TTL 300 in the bind configs for each domain, right?

This might fail. Some providers completely ignore TTL if it doesn't suit
them.

Vic.



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202155513:7E2B86EE-FE56-11DF-9772-EFC0F559ED1D
Powered by Listbox: http://www.listbox.com

At 18:29 02/12/2010 Thursday, Marc Olivé wrote:
>Hi,
>
>Let me please join your conversation in the "asking" part of it.
>
>Andrew, you introduce an interesting question to me:
>
>"If, for example, you hired a marketing company to send communications to your customers. If they sent emails from their servers as you, one option would be to add their servers to your SPF record. (There are other, often better solutions for this.)"
>
>
>Recently, I've recommended a client of us (we are a small web agency offering e-mail marketing solutions) to add our server's ip4 to their SPF record.
>
>Could you suggest a better solution for that case? They send mail to a legitimate list of their customers and interested people, no spamming. They send mail from the servers behind their domain, and we send mail on their behalf from a server we manage.

a common solution is to publish

v=spf1 ip4:myip1 ip4:myip2 etc... ?include:spfrecord-of-esp -all

thus my own ips have a default + pass
the esp who sends mail 'forged as me' but not under my control entirely lists their ip's in an spf record they control {so they can move servers without breaking clients) and i include it wit a ? to say its not me but its not forged treat neutrally, then all others are a - or ~ fail depending on my userbase

another is to do per user spf

v=spf1 redirect=%{l}._spf1.%{d2}

ie lookup localpart._spf1.domain for this users apf

so my-esp-from-address@mydomain has an spf of v=spf1 include:spfrecord-of-esp -all
and me@mydomain has an spf of v=spf1 ip4:myip1 ip4:myip2 etc... -all
and address-that-dosnt-exist@mydomain has an spf of v=spf1 -all

the former is common the latter is my preferred solution, but needs a compitent and diligent admin


>We are completely open to any comment that may help mail filters and handlers correctly qualify our messages.
>
>Regards,
>
>Marc Olivé i Valls
>El Nucli
>________________________________________________________________________________
>Marc Olivé i Valls | <mailto:marc@elnucli.com>marc@elnucli.com | www.elnucli.com
>
><http://www.facebook.com/pages/Manresa-Spain/El-Nucli/128809810270>El Nucli és al Facebook | <http://twitter.com/elnucli>A vegades fem tweets!
>
>El Nucli 9-08, S.L. | Avinguda de les Bases de Manresa 52-58 1er 3a | 08242 • Manresa
>tel: 937.013.260 | fax: 937.013.011
>
>(Abans d'imprimir aquest correu penseu en el vostre compromís amb el medi ambient)
>On Thu, Dec 2, 2010 at 6:48 PM, Andrew Culver <<mailto:aculver@uwo.ca>aculver@uwo.ca> wrote:
>Hi Neil,
>
>
>Neil Gunton wrote:
>Then I don't see when you would ever use -all, because with any public email system you cannot predict in advance who you will be sending messages to. You never have any idea what their forwarding setups are. So why do you say "during testing"? When would this testing phase end, exactly? How could it ever end, given the intrinsic uncertainty of who you might have to send emails to in the future?
>
>
>You'd be testing who is sending mail, not receiving it. It's up to the receivers to decide how to handle your mail and how to act upon your SPF record. All you can do is make sure your record is correct.
>
>
>All I do know is that I definitely want to make it clear to the world that email coming from me can only originate from my server.
>
>
>The the SPF record you mentioned in your last message should work fine.
>
>
>the microsoft one is NOT spf (same syntax totally different system) called senderID, and not compatable
>
>
>Then their web page is extremely misleading, because they use "SPF" in the title:
>
><http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/>http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
>
>
>Yes it is.
>
>
>Anybody (like myself) looking around on the web for SPF wizards to help them construct one of these records might reasonably assume that "SPF is SPF", and use this - the result looks identical to the official SPF to me. This is really bad, especially as you're saying they are actually incompatible.
>
>
>It's not that they're incompatible. If you only publish an SPF record, Sender-ID will use that. However, the behaviour of Sender-ID is different from that of SPF.
>
>It is recommended, that if you do not intend for your SPF record to be used by Sender-ID-aware hosts, that you also publish the following Sender-ID record:
>
>TXT "spf2.0/pra"
>
>If, however, you wish to use Sender-ID, you should research it and publish an appropriate record.
>
>
>but I can't remember. Obviously either I misunderstood the questions the wizard asked me, or else the wizard itself was screwed up.
>
>
>usually the second no wizard i have seen approaches anything near to simple logic.
>
>
>Again, this is bad, most people will try to use the wizards rather than spend their time learning the innards of yet another specification.
>
>
>Most SPF records can be generated by asking the simple question: "What hosts are authorized to send mail for your domain?" Then list the IP addresses of those hosts in your SPF record as you have done.
>
>
>the only ip address that matters is the address of my mail server, is that correct?
>
>
>not entirely, not your mail server, but any mail server that is allowed to send mail to others on your behalf
>
>
>The only server that is allowed to send emails to others as coming from me or any of my website processes is my server. I don't know of any situation where some other server is going to be sending emails to others "on my behalf", isn't that just a recipe for spammers to send email as "me"? It should never happen, as far as I know.
>
>
>If, for example, you hired a marketing company to send communications to your customers. If they sent emails from their servers as you, one option would be to add their servers to your SPF record. (There are other, often better solutions for this.)
>
>
>{for example if your server was only used to receive and you used your isp 'isp-x' to send mail only, then your spf should have no mention of your server just the ip's/mames of the isp-x servers)
>
>
>My email server is used to send and receive all my email.
>
>
>Then the record you have is fine.
>
>
>
>- all means HARDFAIL all others (ie you recommend that they refuse mail from any other source)
>~ all means SOFTFAIL all others (ie you recommend treating other sources with suspicion)
>? all means NEUTRAL all others (ie you recommend treating other sources neither positively(pass) or negatively(fail) just treat them the way you do email with no spf)
>
>
>Given that all mail I send or receive goes from/to this one server, isn't this about as solid a case as you could ever get for using -all?
>
>
>Yes. Not all mail environments are as simple as yours. These options are available to allow for increased/softer testing.
>
>Andrew
>
>
>Thanks again,
>
>Neil
>
>
>-------------------------------------------
>Sender Policy Framework: <http://www.openspf.org>http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: <http://www.listbox.com/member/>http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: <https://www.listbox.com/member/archive/1020/=now>https://www.listbox.com/member/archive/1020/=now
>RSS Feed: <https://www.listbox.com/member/archive/rss/1020/14525495-91eca367>https://www.listbox.com/member/archive/rss/1020/14525495-91eca367
>Modify Your Subscription: <https://www.listbox.com/member/?&>https://www.listbox.com/member/?&
>Unsubscribe Now: <https://www.listbox.com/unsubscribe/?&&post_id=20101202122620:490EFE04-FE39-11DF-8E6B-829DE8F8D026>https://www.listbox.com/unsubscribe/?&&post_id=20101202122620:490EFE04-FE39-11DF-8E6B-829DE8F8D026
>Powered by Listbox: <http://www.listbox.com>http://www.listbox.com
>
>
>
>-------------------------------------------
>Sender Policy Framework: <http://www.openspf.org>http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: <http://www.listbox.com/member/>http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: <https://www.listbox.com/member/archive/1020/=now>https://www.listbox.com/member/archive/1020/=now
>RSS Feed: <https://www.listbox.com/member/archive/rss/1020/20135140-294d0708>https://www.listbox.com/member/archive/rss/1020/20135140-294d0708
>Modify Your Subscription: <https://www.listbox.com/member/?&>https://www.listbox.com/member/?&
>Unsubscribe Now: <https://www.listbox.com/unsubscribe/?&&post_id=20101202124906:73A3F7CA-FE3C-11DF-A52E-8F0DC6F4DBAC>https://www.listbox.com/unsubscribe/?&&post_id=20101202124906:73A3F7CA-FE3C-11DF-A52E-8F0DC6F4DBAC
>
>Powered by Listbox: <http://www.listbox.com>http://www.listbox.com
>
>
>Sender Policy Framework: <http://www.openspf.org>http://www.openspf.org
>Modify Your Subscription: <http://www.listbox.com/member/>http://www.listbox.com/member/
><https://www.listbox.com/member/archive/1020/=now>Archives<https://www.listbox.com/member/archive/rss/1020/15739084-a04d3caa> | <https://www.listbox.com/member/?&>Modify Your Subscription | <https://www.listbox.com/unsubscribe/?&&post_id=20101202132950:2F1EAD2E-FE42-11DF-902B-E392F559ED1D>Unsubscribe Now<http://www.listbox.com>



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202161047:985D4EC4-FE58-11DF-90D3-E5D876EA70E9
Powered by Listbox: http://www.listbox.com

At 18:42 02/12/2010 Thursday, Neil Gunton wrote:
>alan wrote:
>>- all means HARDFAIL all others (ie you recommend that they refuse mail from any other source)
>>~ all means SOFTFAIL all others (ie you recommend treating other sources with suspicion)
>>? all means NEUTRAL all others (ie you recommend treating other sources neither positively(pass) or negatively(fail) just treat them the way you do email with no spf)
>
>Ok, Vic raised excellent points in his previous email about me being part of mailing lists (ironically, including this one) and also Paypal, who sends out emails (I think) as being "from" me. I do use paypal on my site for incoming donations, and I do on occasion paypal other people money, so that might be very relevant.
>
>Accordingly, I have changed to ?all now, as recommended for testing.
>
>The next question is, let's say everything seems to be working fine, at what point would I change this to ~all? Or is ?all a good way to leave it long term?
>
>Would ?all make some email providers treat emails coming from me with any more suspicion than usual, since it is apparently more open to being spoofed? I know it recommends neither positive or negative, but I'm just wondering if some of the more aggressive email filters out there might have a "presumed guilty" policy for more open SPF records.

best way to describe this is look at what others use
gmail ends ?all
hotmail ends ~all
yahoo wont touch spf

in short no real downside

-all is more (IMO) for those of us like me willing to loose mail in order to find/highlight and try and convince them to fix, idiots who do run non whitelisting capable receivers with forwarding, bad(forging) envelope-sender mailinglists etc..

but its not really what i would recommend to any business that has to send mail to every dumbly setup joe out there (and expect it to survive their broken setups)

its also why i do per-user spf thus each of my users with addresses within some of the shared domains i admin gets to pick for themselves ~all -all or ?all


>Thanks again,
>
>Neil
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/15739084-a04d3caa
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101202134308:03B75F08-FE44-11DF-8F2A-ACC28FC971C9
>Powered by Listbox: http://www.listbox.com



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202162118:2507D99C-FE5A-11DF-BAD8-97DF0E28B8C5
Powered by Listbox: http://www.listbox.com

On 12/02/2010 03:22 PM, alan wrote:
>
>> Ok, Vic raised excellent points in his previous email about me being part of mailing lists (ironically, including this one) and also Paypal, who sends out emails (I think) as being "from" me. I do use paypal on my site for incoming donations, and I do on occasion paypal other people money, so that might be very relevant.
>>

The part you keep glossing over: Neither paypal's regular payment
processing (I can't vouch for the subscription system that another
posted mentioned uphthread) nor this mailing list send mail with the
envelope-from as you. In Paypal's case, it was

"Dec 2 18:14:44 sb1 postfix/qmgr[9145]: F27F81C102:
from=<payment@paypal.com>, size=9294, nrcpt=1 (queue active)"

And in the case of the mailing list it was from
listbox+trampoline+gobbledygook@... well .. You can look through your
own MTA logs for the exact value




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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202163416:F2C936CC-FE5B-11DF-A788-8383F559ED1D
Powered by Listbox: http://www.listbox.com

Andrew Culver wrote:
> The Return-path header is indicating what the SMTP MAIL FROM address
> was. This is what SPF recipients look at. In this case, receivers would
> look at the SPF record of paypal.com, not your domain. Paypal is doing
> it right. (See Marc's thread for how someone in Paypal's situation could
> do things wrong.)

I give users on my site the ability to contact other members via a web
form, which hides the recipient's email address and sends the email
behind the scenes on the server. Currently the emails are sent with the
'From' and 'Reply-to' headers set to the name and email of the person
sending the message, which seemed untuitive previously (since they are
effectively sending an email via the website).

However, the above comment about the Return-path header made me check
what that was being set to. In my case, it is being set to the same as
the 'From' address, which is bad because my server may not be allowed to
send email "from" arbitrary addresses.

I think I'd like to instruct my code (or my sendmail) to set the
Return-path header to be an address @ my domain, so that if/when it gets
checked for SPF, it is checked against my domain and not the user who I
am sending on behalf of. But I can't seem to find any way to do this.
Does anybody have any clues on that? Is it something I would set in my
Perl code, or in the sendmail config? Paypal seems to do it, but I have
no idea, it just seems to use whatever is in the 'From' address for
generating the 'Return-path'.

I wonder if this is why some of my contact messages don't get through -
maybe they seem to be coming from other domains (in the Return-path) but
the SPF for those domains obviously won't allow my server to be sending
email for them, so it gets treated as suspicious. Does that make any sense?

Thanks again,

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202182928:002E3834-FE6C-11DF-9585-E3D5C5F4DBAC
Powered by Listbox: http://www.listbox.com

Neil Gunton wrote:
> Andrew Culver wrote:
>> The Return-path header is indicating what the SMTP MAIL FROM address
>> was. This is what SPF recipients look at. In this case, receivers
>> would look at the SPF record of paypal.com, not your domain. Paypal is
>> doing it right. (See Marc's thread for how someone in Paypal's
>> situation could do things wrong.)
>
> I think I'd like to instruct my code (or my sendmail) to set the
> Return-path header to be an address @ my domain, so that if/when it gets
> checked for SPF, it is checked against my domain and not the user who I
> am sending on behalf of. But I can't seem to find any way to do this.
> Does anybody have any clues on that? Is it something I would set in my
> Perl code, or in the sendmail config? Paypal seems to do it, but I have
> no idea, it just seems to use whatever is in the 'From' address for
> generating the 'Return-path'.
>
> I wonder if this is why some of my contact messages don't get through -
> maybe they seem to be coming from other domains (in the Return-path) but
> the SPF for those domains obviously won't allow my server to be sending
> email for them, so it gets treated as suspicious. Does that make any sense?

I did some testing on my website, registering two users - one with my
gmail test address, and another with my yahoo test address. I then
posted a classified on my site with the gmail account, and then logged
on with the yahoo account and sent a contact email to the gmail acount's
classified. Sure enough, when I went to look at the message on Gmail,
the SPF result was only "neutral", presumably because yahoo.com doesn't
have an SPF record at all. If Yahoo did publish one, then that email
might well have not gotten through. I need a way to make my
'Return-path' point to my own domain, rather than one based on the
arbitrary third party 'from' address.

The only way I can currently make this work is via a kludge: Set the
'From' name to be the actual name of the person sending the message, but
the 'from' email address is set to 'notifications@mydomain.com'. I also
set the 'Reply-to' header to be the complete address of the sender, so
that replies will work correctly. So that means the 'From' email address
is now one at my domain, which passes Google's SPF check even though the
email is being sent on behalf of someone else. It has the effect I want,
at least, but somehow it feels kind of dirty, probably because it is.
It's a kludge, but I just wanted to see if it affected the delivery, and
it did.

Is this a bad way to do it? Or is there some other way to get the
Return-path header set properly, as paypal does it?

Thanks again,

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202191553:7FCD1A0A-FE72-11DF-AA72-8E4497CABFD1
Powered by Listbox: http://www.listbox.com

At 23:29 02/12/2010 Thursday, Neil Gunton wrote:
>Andrew Culver wrote:
>>The Return-path header is indicating what the SMTP MAIL FROM address was. This is what SPF recipients look at. In this case, receivers would look at the SPF record of paypal.com, not your domain. Paypal is doing it right. (See Marc's thread for how someone in Paypal's situation could do things wrong.)
>
>I give users on my site the ability to contact other members via a web form, which hides the recipient's email address and sends the email behind the scenes on the server. Currently the emails are sent with the 'From' and 'Reply-to' headers set to the name and email of the person sending the message, which seemed untuitive previously (since they are effectively sending an email via the website).
>
>However, the above comment about the Return-path header made me check what that was being set to. In my case, it is being set to the same as the 'From' address, which is bad because my server may not be allowed to send email "from" arbitrary addresses.
>
>I think I'd like to instruct my code (or my sendmail) to set the Return-path header to be an address @ my domain, so that if/when it gets checked for SPF, it is checked against my domain and not the user who I am sending on behalf of. But I can't seem to find any way to do this. Does anybody have any clues on that? Is it something I would set in my Perl code, or in the sendmail config? Paypal seems to do it, but I have no idea, it just seems to use whatever is in the 'From' address for generating the 'Return-path'.

its set with the -f whatever@domain
the user calling sendmail must be in the 'trusted-user' list (usually apache)

I mentioned this in a previous email, its in the sendmail manual
<http://www.sendmail.com/pdfs/open_source/installation_and_op_guide.pdf>http://www.sendmail.com/pdfs/open_source/installation_and_op_guide.pdf


>I wonder if this is why some of my contact messages don't get through - maybe they seem to be coming from other domains (in the Return-path) but the SPF for those domains obviously won't allow my server to be sending email for them, so it gets treated as suspicious. Does that make any sense?

yes totally

just ensure that the envelope sender you set exists so that you can also read and react to errors/bounces etc


>Thanks again,
>
>Neil
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/15739084-a04d3caa
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101202182928:002E3834-FE6C-11DF-9585-E3D5C5F4DBAC
>Powered by Listbox: http://www.listbox.com



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202202214:C9C5F11E-FE7B-11DF-B75A-0134C6F4DBAC
Powered by Listbox: http://www.listbox.com

At 00:15 03/12/2010 Friday, Neil Gunton wrote:
>Neil Gunton wrote:
>>Andrew Culver wrote:
>>>The Return-path header is indicating what the SMTP MAIL FROM address was. This is what SPF recipients look at. In this case, receivers would look at the SPF record of paypal.com, not your domain. Paypal is doing it right. (See Marc's thread for how someone in Paypal's situation could do things wrong.)
>>I think I'd like to instruct my code (or my sendmail) to set the Return-path header to be an address @ my domain, so that if/when it gets checked for SPF, it is checked against my domain and not the user who I am sending on behalf of. But I can't seem to find any way to do this. Does anybody have any clues on that? Is it something I would set in my Perl code, or in the sendmail config? Paypal seems to do it, but I have no idea, it just seems to use whatever is in the 'From' address for generating the 'Return-path'.
>>I wonder if this is why some of my contact messages don't get through - maybe they seem to be coming from other domains (in the Return-path) but the SPF for those domains obviously won't allow my server to be sending email for them, so it gets treated as suspicious. Does that make any sense?
>
>I did some testing on my website, registering two users - one with my gmail test address, and another with my yahoo test address. I then posted a classified on my site with the gmail account, and then logged on with the yahoo account and sent a contact email to the gmail acount's classified. Sure enough, when I went to look at the message on Gmail, the SPF result was only "neutral", presumably because yahoo.com doesn't have an SPF record at all. If Yahoo did publish one, then that email might well have not gotten through. I need a way to make my 'Return-path' point to my own domain, rather than one based on the arbitrary third party 'from' address.
>
>The only way I can currently make this work is via a kludge: Set the 'From' name to be the actual name of the person sending the message, but the 'from' email address is set to 'notifications@mydomain.com'. I also set the 'Reply-to' header to be the complete address of the sender, so that replies will work correctly. So that means the 'From' email address is now one at my domain, which passes Google's SPF check even though the email is being sent on behalf of someone else. It has the effect I want, at least, but somehow it feels kind of dirty, probably because it is. It's a kludge, but I just wanted to see if it affected the delivery, and it did.
>
>Is this a bad way to do it? Or is there some other way to get the Return-path header set properly, as paypal does it?

see previous mail
though you should also set
from: "theirname" <their@address>
Sender: "theirname" <notifications@mydomain>
Reply-to: "theirname" <their@address>

in case a receiver is using sender-id (idiots) but if they are this will pass their checks


>Thanks again,
>
>Neil
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/15739084-a04d3caa
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101202191553:7FCD1A0A-FE72-11DF-AA72-8E4497CABFD1
>Powered by Listbox: http://www.listbox.com



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202203224:24D45900-FE7D-11DF-8DCA-BE3E2041A22B
Powered by Listbox: http://www.listbox.com

alan wrote:
> see previous mail
> though you should also set
> from: "theirname" <their@address>
> Sender: "theirname" <notifications@mydomain>
> Reply-to: "theirname" <their@address>
>
> in case a receiver is using sender-id (idiots) but if they are this will pass their checks

No, I need to use mydomain in the 'from', because that is what is
apparently being used to generate the 'Return-path' header. So I now have:

from: "theirname" <notifications@mydomain>
Reply-to: "theirname" <their@address>

That seems to work with Google mail. Is this what you meant, or am I
still doing it wrong?

One downside of doing the 'from' this way is that the user could
conceivably click on that address to add to their address book, and it
would be the wrong address.

I have never used the 'Sender' header before, but I don't mind adding it
if it will help with Sender-id.

Thanks again for your patience!

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202204805:69E6E376-FE7F-11DF-921B-862D15C8F5F0
Powered by Listbox: http://www.listbox.com

No, Return-path is indicating what was used in the SMTP MAIL FROM (aka
envelope sender). In an email you have the envelope SMTP commands, then
the headers, then the body or mime parts. You should use
notifications@mydomain in the SMTP MAIL FROM and the rest as alan described.

Andrew

On 02/12/2010 8:48 PM, Neil Gunton wrote:
> alan wrote:
>> see previous mail
>> though you should also set
>> from: "theirname" <their@address>
>> Sender: "theirname" <notifications@mydomain>
>> Reply-to: "theirname" <their@address>
>>
>> in case a receiver is using sender-id (idiots) but if they are this
>> will pass their checks
>
> No, I need to use mydomain in the 'from', because that is what is
> apparently being used to generate the 'Return-path' header. So I now have:
>
> from: "theirname" <notifications@mydomain>
> Reply-to: "theirname" <their@address>
>
> That seems to work with Google mail. Is this what you meant, or am I
> still doing it wrong?
>
> One downside of doing the 'from' this way is that the user could
> conceivably click on that address to add to their address book, and it
> would be the wrong address.
>
> I have never used the 'Sender' header before, but I don't mind adding it
> if it will help with Sender-id.
>
> Thanks again for your patience!
>
> Neil
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/1020/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/1020/14525495-91eca367
> Modify Your Subscription:
> https://www.listbox.com/member/?&
>
> Unsubscribe Now:
> https://www.listbox.com/unsubscribe/?&&post_id=20101202204805:69E6E376-FE7F-11DF-921B-862D15C8F5F0
>
> Powered by Listbox: http://www.listbox.com


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202205243:FB345FFC-FE7F-11DF-B212-FC953AAFA772
Powered by Listbox: http://www.listbox.com

Andrew Culver wrote:
> No, Return-path is indicating what was used in the SMTP MAIL FROM (aka
> envelope sender). In an email you have the envelope SMTP commands, then
> the headers, then the body or mime parts. You should use
> notifications@mydomain in the SMTP MAIL FROM and the rest as alan
> described.

Ok, I don't know how to set the SMTP MAIL FROM. I use a Perl module
called Mail::Sender, which I give parameters like 'from', 'cc' and other
headers. This then connects to my local mail server (sendmail, on the
same machine). Any idea on how I go about setting this SMTP MAIL FROM?
Is that done outside perl in the sendmail config, or from within perl at
send time?

Sorry for my ignorance, there's obviously much I don't know about email.

Thanks for any clues,

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202210446:BE141872-FE81-11DF-9148-B83E41D1E924
Powered by Listbox: http://www.listbox.com

At 02:04 03/12/2010 Friday, Neil Gunton wrote:
>Andrew Culver wrote:
>>No, Return-path is indicating what was used in the SMTP MAIL FROM (aka envelope sender). In an email you have the envelope SMTP commands, then the headers, then the body or mime parts. You should use notifications@mydomain in the SMTP MAIL FROM and the rest as alan described.
>
>Ok, I don't know how to set the SMTP MAIL FROM. I use a Perl module called Mail::Sender, which I give parameters like 'from', 'cc' and other headers. This then connects to my local mail server (sendmail, on the same machine). Any idea on how I go about setting this SMTP MAIL FROM? Is that done outside perl in the sendmail config, or from within perl at send time?
>
>Sorry for my ignorance, there's obviously much I don't know about email.#

as i have said now in the 2 mails you seem to have ignored

its -f <<<<<<<<<<<<<<<<<<<<<<<<<<<
in sendmail (i included a link to the manual searching it for '-f' will give you the details

i have no idea about the perl module between your code and sendmail, if it dosn't offer this basic facility consider using a different perl module one that does

as always to use -f (as mentioned each time before the user running the code must be in the sendmail trusted users)


>Thanks for any clues,
>
>Neil
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/15739084-a04d3caa
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101202210446:BE141872-FE81-11DF-9148-B83E41D1E924
>Powered by Listbox: http://www.listbox.com



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202213002:3B3304D2-FE85-11DF-BB86-438BF559ED1D
Powered by Listbox: http://www.listbox.com

alan wrote:
> At 02:04 03/12/2010 Friday, Neil Gunton wrote:
>> Andrew Culver wrote:
>>> No, Return-path is indicating what was used in the SMTP MAIL FROM (aka envelope sender). In an email you have the envelope SMTP commands, then the headers, then the body or mime parts. You should use notifications@mydomain in the SMTP MAIL FROM and the rest as alan described.
>> Ok, I don't know how to set the SMTP MAIL FROM. I use a Perl module called Mail::Sender, which I give parameters like 'from', 'cc' and other headers. This then connects to my local mail server (sendmail, on the same machine). Any idea on how I go about setting this SMTP MAIL FROM? Is that done outside perl in the sendmail config, or from within perl at send time?
>>
>> Sorry for my ignorance, there's obviously much I don't know about email.#
>
> as i have said now in the 2 mails you seem to have ignored
>
> its -f <<<<<<<<<<<<<<<<<<<<<<<<<<<
> in sendmail (i included a link to the manual searching it for '-f' will give you the details
>
> i have no idea about the perl module between your code and sendmail, if it dosn't offer this basic facility consider using a different perl module one that does
>
> as always to use -f (as mentioned each time before the user running the code must be in the sendmail trusted users)

Ah, ok, I'm sorry I missed that. I am not currently calling sendmail
directly, I have never done it that way in fact, but I do seem to
remember seeing references to it. I will do some research to see how I
can convert my existing code to this method. I'm quite happy to change
it if it means I can get better control over SMTP MAIL FROM.

I wasn't intentionally ignoring your previous advice, it just didn't
"click". Sorry about that.

Thanks again,

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101202213949:9BB75852-FE86-11DF-BB9E-BE20E4F39B96
Powered by Listbox: http://www.listbox.com

> Ok, I don't know how to set the SMTP MAIL FROM. I use a Perl module
> called Mail::Sender, which I give parameters like 'from', 'cc' and other
> headers.

http://search.cpan.org/~jenda/Mail-Sender-0.8.16/Sender.pm has the man
page for Mail::Sender.

It specifies using the parameter "replyto" to set the reply-to address.
This will doubtless require the calling process to be owned by one of the
MTA's trusted users.

Vic.



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101203035133:7DE52C3A-FEBA-11DF-A36C-FDC53D8652E9
Powered by Listbox: http://www.listbox.com

Parameters

from

fake_from


If not specified we use the value of from.



It looks like you can use from to specify the SMTP MAIL FROM and then
fake_from to set a From: header. If no fake_from is specified, the from
address is used in the From: header.

Andrew



Vic wrote:
>> Ok, I don't know how to set the SMTP MAIL FROM. I use a Perl module
>> called Mail::Sender, which I give parameters like 'from', 'cc' and other
>> headers.
>
> http://search.cpan.org/~jenda/Mail-Sender-0.8.16/Sender.pm has the man
> page for Mail::Sender.
>
> It specifies using the parameter "replyto" to set the reply-to address.
> This will doubtless require the calling process to be owned by one of the
> MTA's trusted users.
>
> Vic.
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/1020/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/1020/14525495-91eca367
> Modify Your Subscription: https://www.listbox.com/member/?&
> Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101203035133:7DE52C3A-FEBA-11DF-A36C-FDC53D8652E9
> Powered by Listbox: http://www.listbox.com


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101203101353:FBBBD912-FEEF-11DF-83FE-B84232BEB856
Powered by Listbox: http://www.listbox.com

Ho ricevuto il messaggio. Sono in ferie fino al 16 dicembre, legger� il messaggio al mio rientro il 17 dicembre.
Per cose urgenti potete scrivere a info@biatwork.com, i miei colleghi prenderanno in carico la vostra email.

Cordiali saluti
Massimo Gregori





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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101203101528:27E86F0A-FEF0-11DF-9BA5-1D16C6F4DBAC
Powered by Listbox: http://www.listbox.com

On Thursday, December 02, 2010 02:31:45 pm Andrew Culver wrote:
> Neil Gunton wrote:
> >> It is recommended, that if you do not intend for your SPF record to be
> >> used by Sender-ID-aware hosts, that you also publish the following
> >> Sender-ID record:
> >>
> >> TXT "spf2.0/pra"
> >>
> >> If, however, you wish to use Sender-ID, you should research it and
> >> publish an appropriate record.
> >
> > Is there much benefit to going to that trouble? Will hosts that use
> > Sender-ID be able to see from my existing SPF record that the email is
> > genuine? They are so similar, I don't see why we need a different
> > standard. In fact the worst case is when it is "similar but different",
> > in my experience. Oh, sorry, I forgot we're talking about Microsoft
> > here. Carry on.
>
> SPF acts on the SMTP MAIL FROM address (and sometimes the HELO address).
>
> Sender-ID goes beyond this and tries to figure out what the Purported
> Responsible Address (PRA) of the sender is and then check the Sender-ID
> record of that address's domain. Sounds good in theory, however this is
> easily fooled and so essentially useless.
>
> What's worse, is Sender-ID implementations will use the SPF record if no
> Sender-ID record exists. Although Sender-ID adoption is much less an
> SPF, it can still cause delivery problems to those hosts that use it if
> the sending domain lacks correct records, which is why the "spf2.0/pra"
> record is recommended to prevent this fall-back.

By who? Unless your domain uses a third party sender that uses their own Mail
From and your body From this isn't required.

Much more common is that PRA ends up being some unrelated domain due to added
headers and publishing your own SIDF record won't affect that.

Scott K


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101203105805:1C50E3C4-FEF6-11DF-A5F6-691DC6F4DBAC
Powered by Listbox: http://www.listbox.com

On Thursday, December 02, 2010 01:29:42 pm Marc Olivé wrote:
> Hi,
>
> Let me please join your conversation in the "asking" part of it.
>
> Andrew, you introduce an interesting question to me:
>
> *"If, for example, you hired a marketing company to send communications to
> your customers. If they sent emails from their servers as you, one option
> would be to add their servers to your SPF record. (There are other, often
> better solutions for this.)"*
>
>
> Recently, I've recommended a client of us (we are a small web agency
> offering e-mail marketing solutions) to add our server's ip4 to their SPF
> record.
>
> Could you suggest a better solution for that case? They send mail to a
> legitimate list of their customers and interested people, no spamming. They
> send mail from the servers behind their domain, and we send mail on their
> behalf from a server we manage.
>
> We are completely open to any comment that may help mail filters and
> handlers correctly qualify our messages.

Asking customers to modify their SPF records is not a very scalable solution.
If you are acting as a transparent forwarder, the recommended solution for SPF
is to rewrite Mail From to your own preferred bounce address. To avoid
SenderID incompatibility, add a related Sender to the body with an associated
SenderID record. This avoids the need for your customers to change their DNS.

Scott K


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101203110121:97349FFE-FEF6-11DF-998E-DC99F559ED1D
Powered by Listbox: http://www.listbox.com

Andrew Culver wrote:
> Parameters
> from
> => the sender's e-mail address
> fake_from
> => the address that will be shown in headers.
> If not specified we use the value of from.
> It looks like you can use from to specify the SMTP MAIL FROM and then
> fake_from to set a From: header. If no fake_from is specified, the from
> address is used in the From: header.

Yes, you seem to be correct - I just tried this out with my existing
Mail::Sender code and it seems to work exactly as you say. I set
'fake_from' to be the actual recipient address, and 'from' to be an
arbitrary address at my domain just for the sake of SPF checking
(notifications@crazyguyonabike.com), and then I sent an email from my
website contact form, going from a third party address to another third
party address (both mine, but from yahoo to gmail). When I checked the
headers on the recipient message, Return-Path had indeed been set to the
notifications address, which made the SPF check happy (since now it
checks it against my domain's SPF and not the third party's). Done this
way, I don't seem to need to add anything to sendmail's "trusted users"
either.

Thanks very much - that seems to accomplish exactly what I need! I did
not understand the point of 'fake_from' before, but now I do.

I think this will help a lot with getting my users' emails delivered
more reliably - I'm very appreciative, and thanks again for your patience.

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101203125201:04C2CCC6-FF06-11DF-B88C-0D28C6F4DBAC
Powered by Listbox: http://www.listbox.com

Vic wrote:
> http://search.cpan.org/~jenda/Mail-Sender-0.8.16/Sender.pm has the man
> page for Mail::Sender.
>
> It specifies using the parameter "replyto" to set the reply-to address.
> This will doubtless require the calling process to be owned by one of the
> MTA's trusted users.

I already specify reply-to, and it doesn't seem to require doing
anything special with regard to the trusted users - it just adds the
'Reply-to' header but doesn't affect 'Return-path'. Andrew's suggestion
on using fake_from seems to have done the trick for setting Return-Path.

Thanks again,

Neil


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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101203125438:647BC74E-FF06-11DF-BB28-CCBDC30D0016
Powered by Listbox: http://www.listbox.com

>
>> What's worse, is Sender-ID implementations will use the SPF record if no
>> Sender-ID record exists. Although Sender-ID adoption is much less an
>> SPF, it can still cause delivery problems to those hosts that use it if
>> the sending domain lacks correct records, which is why the "spf2.0/pra"
>> record is recommended to prevent this fall-back.
>
>By who? Unless your domain uses a third party sender that uses their own Mail
> From and your body From this isn't required.

err most mailinglists for one
and all SRS compatable forwarders for another


>Much more common is that PRA ends up being some unrelated domain due to added
>headers and publishing your own SIDF record won't affect that.
>
>Scott K
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/1020/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/1020/15739084-a04d3caa
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20101203105805:1C50E3C4-FEF6-11DF-A5F6-691DC6F4DBAC
>Powered by Listbox: http://www.listbox.com



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

Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/1311530-08394398
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311530&id_secret=1311530-644bccd5
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311530&id_secret=1311530-512c0f9e&post_id=20101204051338:1E317B2E-FF8F-11DF-AA57-E10C7F7F7319
Powered by Listbox: http://www.listbox.com