Re: [Declude.JunkMail] OT: SPF record question
Thanks for that tip Shayne. It seems that my SPF implementation is passed by gmail. Original Message > From: "Shayne Embry" <[EMAIL PROTECTED]> > Sent: Sunday, February 18, 2007 9:30 AM > To: declude.junkmail@declude.com > Subject: Re: [Declude.JunkMail] OT: SPF record question > > Gary, > > One good way to check your SPF implementation is to send a message to a gmail > account. Gmail will allow you to see the entire message header and includes a > line showing that Google checks for SPF. > > Shayne > > > Original Message > > From: "Shayne Embry" <[EMAIL PROTECTED]> > > Sent: Sunday, February 18, 2007 8:06 AM > > To: declude.junkmail@declude.com > > Subject: Re: [Declude.JunkMail] OT: SPF record question > > > > Gary, > > > > You are correct. Message from authenticated accounts to other accounts on > > your server will show the originating IP as the last hop. Be assured, this > > is not the case with messages leaving your server bound for other > > locations. We've been using SPF and SmarterMail successfully for several > > years; in fact, it has saved our butts on several occasions. > > > > As for Hotmail, Yahoo, AOL and the like, it's always a crap shoot anyway. > > We have one client that sends a weekly newsletter; one week everything runs > > smoothly and the next we'll get 100 messages back from Yahoo. We've given > > up trying to figure it out, but SPF is not the culprit. > > > > Shayne Embry > > > > > > > > Original Message > > > From: "Gary Steiner" <[EMAIL PROTECTED]> > > > Sent: Sunday, February 18, 2007 1:54 AM > > > To: declude.junkmail@declude.com > > > Subject: Re: [Declude.JunkMail] OT: SPF record question > > > > > > No, I never belived that the SPF check was run against all the received > > > headers. I'm just looking at how Declude does its SPF check on email > > > that comes into my server. It always does it on the last hop. But > > > looking at the headers of the outgoing messages, (as I showed in my > > > message below from February 16, 2007 4:10 PM), the last hop is shown as > > > the IP address of the originating Outlook sender. This is why I am > > > confused. Maybe this is a flaw in SmarterMail in that it does not list > > > itself in the headers of messages that are internal to the server. > > > > > > I'm just not comfortable with SPF and am worried that I am shooting > > > myself in the foot by providing a method for other servers to block my > > > legitimate mail. I probably should have done more testing first, but I > > > don't really have a good way to specifically check for SPF validity. For > > > example, I created a Yahoo account and a Hotmail account. I sent email > > > from my server to each. Hotmail sent my message to its junkmail folder, > > > Yahoo did not. I have no way to know why Hotmail chose to flag the email > > > as junk and Yahoo did not, as neither add any spam checking messages to > > > the header. I can see that both do list my mail server as the last hop > > > and not the originating Outlook computer as the messages in my server's > > > webmail do. > > > > > > At this point maybe I will just wait and see if any of my customers > > > complain about bounced mail. If I don't hear any complaints, then I > > > (probably) don't have anything to worry about. > > > > > > Gary > > > > > > > --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: SPF record question
Gary, One good way to check your SPF implementation is to send a message to a gmail account. Gmail will allow you to see the entire message header and includes a line showing that Google checks for SPF. Shayne Original Message > From: "Shayne Embry" <[EMAIL PROTECTED]> > Sent: Sunday, February 18, 2007 8:06 AM > To: declude.junkmail@declude.com > Subject: Re: [Declude.JunkMail] OT: SPF record question > > Gary, > > You are correct. Message from authenticated accounts to other accounts on > your server will show the originating IP as the last hop. Be assured, this is > not the case with messages leaving your server bound for other locations. > We've been using SPF and SmarterMail successfully for several years; in fact, > it has saved our butts on several occasions. > > As for Hotmail, Yahoo, AOL and the like, it's always a crap shoot anyway. We > have one client that sends a weekly newsletter; one week everything runs > smoothly and the next we'll get 100 messages back from Yahoo. We've given up > trying to figure it out, but SPF is not the culprit. > > Shayne Embry > > > > Original Message > > From: "Gary Steiner" <[EMAIL PROTECTED]> > > Sent: Sunday, February 18, 2007 1:54 AM > > To: declude.junkmail@declude.com > > Subject: Re: [Declude.JunkMail] OT: SPF record question > > > > No, I never belived that the SPF check was run against all the received > > headers. I'm just looking at how Declude does its SPF check on email that > > comes into my server. It always does it on the last hop. But looking at > > the headers of the outgoing messages, (as I showed in my message below from > > February 16, 2007 4:10 PM), the last hop is shown as the IP address of the > > originating Outlook sender. This is why I am confused. Maybe this is a > > flaw in SmarterMail in that it does not list itself in the headers of > > messages that are internal to the server. > > > > I'm just not comfortable with SPF and am worried that I am shooting myself > > in the foot by providing a method for other servers to block my legitimate > > mail. I probably should have done more testing first, but I don't really > > have a good way to specifically check for SPF validity. For example, I > > created a Yahoo account and a Hotmail account. I sent email from my server > > to each. Hotmail sent my message to its junkmail folder, Yahoo did not. I > > have no way to know why Hotmail chose to flag the email as junk and Yahoo > > did not, as neither add any spam checking messages to the header. I can > > see that both do list my mail server as the last hop and not the > > originating Outlook computer as the messages in my server's webmail do. > > > > At this point maybe I will just wait and see if any of my customers > > complain about bounced mail. If I don't hear any complaints, then I > > (probably) don't have anything to worry about. > > > > Gary > > --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: SPF record question
Gary, You are correct. Message from authenticated accounts to other accounts on your server will show the originating IP as the last hop. Be assured, this is not the case with messages leaving your server bound for other locations. We've been using SPF and SmarterMail successfully for several years; in fact, it has saved our butts on several occasions. As for Hotmail, Yahoo, AOL and the like, it's always a crap shoot anyway. We have one client that sends a weekly newsletter; one week everything runs smoothly and the next we'll get 100 messages back from Yahoo. We've given up trying to figure it out, but SPF is not the culprit. Shayne Embry Original Message > From: "Gary Steiner" <[EMAIL PROTECTED]> > Sent: Sunday, February 18, 2007 1:54 AM > To: declude.junkmail@declude.com > Subject: Re: [Declude.JunkMail] OT: SPF record question > > No, I never belived that the SPF check was run against all the received > headers. I'm just looking at how Declude does its SPF check on email that > comes into my server. It always does it on the last hop. But looking at the > headers of the outgoing messages, (as I showed in my message below from > February 16, 2007 4:10 PM), the last hop is shown as the IP address of the > originating Outlook sender. This is why I am confused. Maybe this is a flaw > in SmarterMail in that it does not list itself in the headers of messages > that are internal to the server. > > I'm just not comfortable with SPF and am worried that I am shooting myself in > the foot by providing a method for other servers to block my legitimate mail. > I probably should have done more testing first, but I don't really have a > good way to specifically check for SPF validity. For example, I created a > Yahoo account and a Hotmail account. I sent email from my server to each. > Hotmail sent my message to its junkmail folder, Yahoo did not. I have no way > to know why Hotmail chose to flag the email as junk and Yahoo did not, as > neither add any spam checking messages to the header. I can see that both do > list my mail server as the last hop and not the originating Outlook computer > as the messages in my server's webmail do. > > At this point maybe I will just wait and see if any of my customers complain > about bounced mail. If I don't hear any complaints, then I (probably) don't > have anything to worry about. > > Gary > > > Original Message > > From: "Michael Thomas - Mathbox" <[EMAIL PROTECTED]> > > Sent: Sunday, February 18, 2007 12:03 AM > > To: declude.junkmail@declude.com > > Subject: RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > > > Darin, > > > > I am not sure why, but Gary seems to think SPF checks are run against ALL of > > the received headers. > > > > I am guessing that he has an SPF test action at the end of his Global.cfg, > > so that it is testing outgoing? > > > > Michael Thomas > > Mathbox > > 978-683-6718 > > 1-877-MATHBOX (Toll Free) > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > > Behalf Of Darin Cox > > > Sent: Saturday, February 17, 2007 11:37 PM > > > To: declude.junkmail@declude.com > > > Subject: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > > > > > Yes, it does. Message come in from your mail client and is > > > whitelisted by > > > SMTP AUTH. Now your server sends it to the destination. > > > Receiving server > > > sees the message coming from your server, and that your > > > server is a valid > > > sender for the domain in question according to your SPF policy. > > > > > > The last hop seen by the destination is your server, not your > > > mail client. > > > Your server satisfies your SPF policy, therefore the > > > receiving server checks > > > and records an SPF PASS. > > > > > > Forget about the client, as long as they send through your > > > server, and you > > > don't filter them out... either because they AUTH and you > > > whitelist on AUTH, > > > or any other way you avoid filtering your connecting users. > > > Its all about > > > your server sending to the destination server. > > > > > > This has been working for us for the past year and a half or so. > > > > > > Darin. > > > > > > > > > - Original Message - > > > From: "Gary Steiner"
Re: [Declude.JunkMail] OT: SPF record question
No, I never belived that the SPF check was run against all the received headers. I'm just looking at how Declude does its SPF check on email that comes into my server. It always does it on the last hop. But looking at the headers of the outgoing messages, (as I showed in my message below from February 16, 2007 4:10 PM), the last hop is shown as the IP address of the originating Outlook sender. This is why I am confused. Maybe this is a flaw in SmarterMail in that it does not list itself in the headers of messages that are internal to the server. I'm just not comfortable with SPF and am worried that I am shooting myself in the foot by providing a method for other servers to block my legitimate mail. I probably should have done more testing first, but I don't really have a good way to specifically check for SPF validity. For example, I created a Yahoo account and a Hotmail account. I sent email from my server to each. Hotmail sent my message to its junkmail folder, Yahoo did not. I have no way to know why Hotmail chose to flag the email as junk and Yahoo did not, as neither add any spam checking messages to the header. I can see that both do list my mail server as the last hop and not the originating Outlook computer as the messages in my server's webmail do. At this point maybe I will just wait and see if any of my customers complain about bounced mail. If I don't hear any complaints, then I (probably) don't have anything to worry about. Gary Original Message > From: "Michael Thomas - Mathbox" <[EMAIL PROTECTED]> > Sent: Sunday, February 18, 2007 12:03 AM > To: declude.junkmail@declude.com > Subject: RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > Darin, > > I am not sure why, but Gary seems to think SPF checks are run against ALL of > the received headers. > > I am guessing that he has an SPF test action at the end of his Global.cfg, > so that it is testing outgoing? > > Michael Thomas > Mathbox > 978-683-6718 > 1-877-MATHBOX (Toll Free) > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Darin Cox > > Sent: Saturday, February 17, 2007 11:37 PM > > To: declude.junkmail@declude.com > > Subject: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > > > Yes, it does. Message come in from your mail client and is > > whitelisted by > > SMTP AUTH. Now your server sends it to the destination. > > Receiving server > > sees the message coming from your server, and that your > > server is a valid > > sender for the domain in question according to your SPF policy. > > > > The last hop seen by the destination is your server, not your > > mail client. > > Your server satisfies your SPF policy, therefore the > > receiving server checks > > and records an SPF PASS. > > > > Forget about the client, as long as they send through your > > server, and you > > don't filter them out... either because they AUTH and you > > whitelist on AUTH, > > or any other way you avoid filtering your connecting users. > > Its all about > > your server sending to the destination server. > > > > This has been working for us for the past year and a half or so. > > > > Darin. > > > > > > - Original Message - > > From: "Gary Steiner" <[EMAIL PROTECTED]> > > To: > > Sent: Saturday, February 17, 2007 11:22 PM > > Subject: Re: [Declude.JunkMail] OT: SPF record question > > > > > > My question still isn't coming across. In setting up SPF, I > > don't want any > > outgoing messages from my server to be bounced by others > > because of a bad > > SPF string. I can whitelist SMTP auth on my server, but that > > does't help > > the SPF problem because potentially when one of my users > > sends a message to > > someone, say on hotmail.com, it could get bounced because of bad SPF. > > > > For example, say my SPF string for my domain is "v=spf1 mx > > mx:smtp.mydomain.com -all". This allows any email sent via > > my SmarterMail > > webmail to pass SPF. Now, if one of my users connects to the > > server with > > Outlook and SMTP Auth, and uses this to send an email, then > > the IP address > > that shows up in the last hop is the one he used to connect > > to my sever, not > > the IP address of my server. So the email message he sends > > would fail SPF. > > For it to pass, I would have to change my SPF string to "v=spf1 mx > > mx:smtp.mydomain.c
RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question
Darin, I am not sure why, but Gary seems to think SPF checks are run against ALL of the received headers. I am guessing that he has an SPF test action at the end of his Global.cfg, so that it is testing outgoing? Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Darin Cox > Sent: Saturday, February 17, 2007 11:37 PM > To: declude.junkmail@declude.com > Subject: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > Yes, it does. Message come in from your mail client and is > whitelisted by > SMTP AUTH. Now your server sends it to the destination. > Receiving server > sees the message coming from your server, and that your > server is a valid > sender for the domain in question according to your SPF policy. > > The last hop seen by the destination is your server, not your > mail client. > Your server satisfies your SPF policy, therefore the > receiving server checks > and records an SPF PASS. > > Forget about the client, as long as they send through your > server, and you > don't filter them out... either because they AUTH and you > whitelist on AUTH, > or any other way you avoid filtering your connecting users. > Its all about > your server sending to the destination server. > > This has been working for us for the past year and a half or so. > > Darin. > > > - Original Message - > From: "Gary Steiner" <[EMAIL PROTECTED]> > To: > Sent: Saturday, February 17, 2007 11:22 PM > Subject: Re: [Declude.JunkMail] OT: SPF record question > > > My question still isn't coming across. In setting up SPF, I > don't want any > outgoing messages from my server to be bounced by others > because of a bad > SPF string. I can whitelist SMTP auth on my server, but that > does't help > the SPF problem because potentially when one of my users > sends a message to > someone, say on hotmail.com, it could get bounced because of bad SPF. > > For example, say my SPF string for my domain is "v=spf1 mx > mx:smtp.mydomain.com -all". This allows any email sent via > my SmarterMail > webmail to pass SPF. Now, if one of my users connects to the > server with > Outlook and SMTP Auth, and uses this to send an email, then > the IP address > that shows up in the last hop is the one he used to connect > to my sever, not > the IP address of my server. So the email message he sends > would fail SPF. > For it to pass, I would have to change my SPF string to "v=spf1 mx > mx:smtp.mydomain.com ip4:67.189.34.6 -all", and additionally > add a ip4: > entry for every instance that a user might connect to my > server with Outlook > . > > So does this mean that SPF is impractical for anyone not > strictly using > webmail? To me it implies that to cover all bases you would > have to have in > your SPF string "?all" and there would be no way to make it > stricter than > that, other than to force all your users to use webmail and > not Outlook. > > Gary > > > > Original Message > > From: "Darin Cox" <[EMAIL PROTECTED]> > > Sent: Friday, February 16, 2007 4:33 PM > > To: declude.junkmail@declude.com > > Subject: Re: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF > record question > > > > Whitelisting SMTP Auth is the key here. Since you connect with a > userID/PW > > to your mail server, Whitelisting connections done through SMTP AUTH > > bypasses Declude filtering. > > > > Darin. > > > > > > - Original Message - > > From: "Gary Steiner" <[EMAIL PROTECTED]> > > To: > > Sent: Friday, February 16, 2007 4:10 PM > > Subject: RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF > record question > > > > > > Let me give you my case. For this example I used my home Comcast > connection > > to send an email using Outlook and authentication. My > server uses Declude > > and SmarterMail. The header of the received message shows > one IP address > in > > a single Received line: > > > > Received: from c-67-189-34-6.hsd1.or.comcast.net [67.189.34.6] by > > mail.plusultraweb.com with SMTP; > >Fri, 16 Feb 2007 15:43:21 -0500 > > > > Michael's message via Declude's mailing list had three > Received lines: > > > > Received: from smtp.declude.com [63.246.31.248] by > mail.plusultraweb.com > > with SMTP; > >Fri, 16 Feb 2007 15:46:48 -0500 > > Received: from mail.mathbox.com [63.150.236.14]
RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question
Gary, I thought I tried to get this across. Most servers check SPF at the connection, not via the received headers. Further excepting very special circumstances like having proxies or gateways, anyone checking SPF via received headers should only be checking the first received header, which means only from your server to the destination server. Again, excepting very special circumstances like having proxies or gateways, checking SPF any deeper than the first received header would be applying SPF rules incorrectly. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Gary Steiner > Sent: Saturday, February 17, 2007 11:23 PM > To: declude.junkmail@declude.com > Subject: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > My question still isn't coming across. In setting up SPF, I > don't want any outgoing messages from my server to be bounced > by others because of a bad SPF string. I can whitelist SMTP > auth on my server, but that does't help the SPF problem > because potentially when one of my users sends a message to > someone, say on hotmail.com, it could get bounced because of bad SPF. > > For example, say my SPF string for my domain is "v=spf1 mx > mx:smtp.mydomain.com -all". This allows any email sent via > my SmarterMail webmail to pass SPF. Now, if one of my users > connects to the server with Outlook and SMTP Auth, and uses > this to send an email, then the IP address that shows up in > the last hop is the one he used to connect to my sever, not > the IP address of my server. So the email message he sends > would fail SPF. For it to pass, I would have to change my > SPF string to "v=spf1 mx mx:smtp.mydomain.com ip4:67.189.34.6 > -all", and additionally add a ip4: entry for every instance > that a user might connect to my server with Outlook . > > So does this mean that SPF is impractical for anyone not > strictly using webmail? To me it implies that to cover all > bases you would have to have in your SPF string "?all" and > there would be no way to make it stricter than that, other > than to force all your users to use webmail and not Outlook. > > Gary > > > > Original Message > > From: "Darin Cox" <[EMAIL PROTECTED]> > > Sent: Friday, February 16, 2007 4:33 PM > > To: declude.junkmail@declude.com > > Subject: Re: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF > record question > > > > Whitelisting SMTP Auth is the key here. Since you connect > with a userID/PW > > to your mail server, Whitelisting connections done through SMTP AUTH > > bypasses Declude filtering. > > > > Darin. > > > > > > - Original Message - > > From: "Gary Steiner" <[EMAIL PROTECTED]> > > To: > > Sent: Friday, February 16, 2007 4:10 PM > > Subject: RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF > record question > > > > > > Let me give you my case. For this example I used my home > Comcast connection > > to send an email using Outlook and authentication. My > server uses Declude > > and SmarterMail. The header of the received message shows > one IP address in > > a single Received line: > > > > Received: from c-67-189-34-6.hsd1.or.comcast.net [67.189.34.6] by > > mail.plusultraweb.com with SMTP; > >Fri, 16 Feb 2007 15:43:21 -0500 > > > > Michael's message via Declude's mailing list had three > Received lines: > > > > Received: from smtp.declude.com [63.246.31.248] by > mail.plusultraweb.com > > with SMTP; > >Fri, 16 Feb 2007 15:46:48 -0500 > > Received: from mail.mathbox.com [63.150.236.14] by > smtp.declude.com with > > SMTP; > >Fri, 16 Feb 2007 15:31:18 -0500 > > Received: from mikesplace [63.150.236.3] by > mail.mathbox.com with ESMTP > > (SMTPD-8.22) id A48F027C; Fri, 16 Feb 2007 15:31:11 -0500 > > > > In both messages Declude made checks versus the last hop > only (67.189.34.6 > > in my test message and 63.246.31.248 in the message from > Declude's mailing > > list. > > > > Since my Comcast IP address is not listed in my SPF string, > it failed > > Declude's SPF test. > > > > So what is the problem here? Is this a flaw in how > SmarterMail lists its > > hops? Should it be showing the Comcast IP address as the > final hop, or > > should it be showing my mail server? > > > > Since it is showing the Comcast address, SPF fails. The > only way to get &g
Re: [Declude.JunkMail] OT: SPF record question
Yes, it does. Message come in from your mail client and is whitelisted by SMTP AUTH. Now your server sends it to the destination. Receiving server sees the message coming from your server, and that your server is a valid sender for the domain in question according to your SPF policy. The last hop seen by the destination is your server, not your mail client. Your server satisfies your SPF policy, therefore the receiving server checks and records an SPF PASS. Forget about the client, as long as they send through your server, and you don't filter them out... either because they AUTH and you whitelist on AUTH, or any other way you avoid filtering your connecting users. Its all about your server sending to the destination server. This has been working for us for the past year and a half or so. Darin. - Original Message - From: "Gary Steiner" <[EMAIL PROTECTED]> To: Sent: Saturday, February 17, 2007 11:22 PM Subject: Re: [Declude.JunkMail] OT: SPF record question My question still isn't coming across. In setting up SPF, I don't want any outgoing messages from my server to be bounced by others because of a bad SPF string. I can whitelist SMTP auth on my server, but that does't help the SPF problem because potentially when one of my users sends a message to someone, say on hotmail.com, it could get bounced because of bad SPF. For example, say my SPF string for my domain is "v=spf1 mx mx:smtp.mydomain.com -all". This allows any email sent via my SmarterMail webmail to pass SPF. Now, if one of my users connects to the server with Outlook and SMTP Auth, and uses this to send an email, then the IP address that shows up in the last hop is the one he used to connect to my sever, not the IP address of my server. So the email message he sends would fail SPF. For it to pass, I would have to change my SPF string to "v=spf1 mx mx:smtp.mydomain.com ip4:67.189.34.6 -all", and additionally add a ip4: entry for every instance that a user might connect to my server with Outlook . So does this mean that SPF is impractical for anyone not strictly using webmail? To me it implies that to cover all bases you would have to have in your SPF string "?all" and there would be no way to make it stricter than that, other than to force all your users to use webmail and not Outlook. Gary Original Message > From: "Darin Cox" <[EMAIL PROTECTED]> > Sent: Friday, February 16, 2007 4:33 PM > To: declude.junkmail@declude.com > Subject: Re: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > Whitelisting SMTP Auth is the key here. Since you connect with a userID/PW > to your mail server, Whitelisting connections done through SMTP AUTH > bypasses Declude filtering. > > Darin. > > > - Original Message - > From: "Gary Steiner" <[EMAIL PROTECTED]> > To: > Sent: Friday, February 16, 2007 4:10 PM > Subject: RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > > Let me give you my case. For this example I used my home Comcast connection > to send an email using Outlook and authentication. My server uses Declude > and SmarterMail. The header of the received message shows one IP address in > a single Received line: > > Received: from c-67-189-34-6.hsd1.or.comcast.net [67.189.34.6] by > mail.plusultraweb.com with SMTP; >Fri, 16 Feb 2007 15:43:21 -0500 > > Michael's message via Declude's mailing list had three Received lines: > > Received: from smtp.declude.com [63.246.31.248] by mail.plusultraweb.com > with SMTP; >Fri, 16 Feb 2007 15:46:48 -0500 > Received: from mail.mathbox.com [63.150.236.14] by smtp.declude.com with > SMTP; >Fri, 16 Feb 2007 15:31:18 -0500 > Received: from mikesplace [63.150.236.3] by mail.mathbox.com with ESMTP > (SMTPD-8.22) id A48F027C; Fri, 16 Feb 2007 15:31:11 -0500 > > In both messages Declude made checks versus the last hop only (67.189.34.6 > in my test message and 63.246.31.248 in the message from Declude's mailing > list. > > Since my Comcast IP address is not listed in my SPF string, it failed > Declude's SPF test. > > So what is the problem here? Is this a flaw in how SmarterMail lists its > hops? Should it be showing the Comcast IP address as the final hop, or > should it be showing my mail server? > > Since it is showing the Comcast address, SPF fails. The only way to get > around this is to end the SPF string with "?all", but if I'm going to do > that, I might as well not use SPF at all. > > Gary > > > Original Message > > From: "Michael Thomas - Mathbox" <[EMAIL PROTECTED]> > > Sent: Friday, February 16, 2007 3:47 PM > > To: declude.junkmail@declude.com > > Subje
Re: [Declude.JunkMail] OT: SPF record question
My question still isn't coming across. In setting up SPF, I don't want any outgoing messages from my server to be bounced by others because of a bad SPF string. I can whitelist SMTP auth on my server, but that does't help the SPF problem because potentially when one of my users sends a message to someone, say on hotmail.com, it could get bounced because of bad SPF. For example, say my SPF string for my domain is "v=spf1 mx mx:smtp.mydomain.com -all". This allows any email sent via my SmarterMail webmail to pass SPF. Now, if one of my users connects to the server with Outlook and SMTP Auth, and uses this to send an email, then the IP address that shows up in the last hop is the one he used to connect to my sever, not the IP address of my server. So the email message he sends would fail SPF. For it to pass, I would have to change my SPF string to "v=spf1 mx mx:smtp.mydomain.com ip4:67.189.34.6 -all", and additionally add a ip4: entry for every instance that a user might connect to my server with Outlook . So does this mean that SPF is impractical for anyone not strictly using webmail? To me it implies that to cover all bases you would have to have in your SPF string "?all" and there would be no way to make it stricter than that, other than to force all your users to use webmail and not Outlook. Gary Original Message > From: "Darin Cox" <[EMAIL PROTECTED]> > Sent: Friday, February 16, 2007 4:33 PM > To: declude.junkmail@declude.com > Subject: Re: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > Whitelisting SMTP Auth is the key here. Since you connect with a userID/PW > to your mail server, Whitelisting connections done through SMTP AUTH > bypasses Declude filtering. > > Darin. > > > - Original Message - > From: "Gary Steiner" <[EMAIL PROTECTED]> > To: > Sent: Friday, February 16, 2007 4:10 PM > Subject: RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > > Let me give you my case. For this example I used my home Comcast connection > to send an email using Outlook and authentication. My server uses Declude > and SmarterMail. The header of the received message shows one IP address in > a single Received line: > > Received: from c-67-189-34-6.hsd1.or.comcast.net [67.189.34.6] by > mail.plusultraweb.com with SMTP; >Fri, 16 Feb 2007 15:43:21 -0500 > > Michael's message via Declude's mailing list had three Received lines: > > Received: from smtp.declude.com [63.246.31.248] by mail.plusultraweb.com > with SMTP; >Fri, 16 Feb 2007 15:46:48 -0500 > Received: from mail.mathbox.com [63.150.236.14] by smtp.declude.com with > SMTP; >Fri, 16 Feb 2007 15:31:18 -0500 > Received: from mikesplace [63.150.236.3] by mail.mathbox.com with ESMTP > (SMTPD-8.22) id A48F027C; Fri, 16 Feb 2007 15:31:11 -0500 > > In both messages Declude made checks versus the last hop only (67.189.34.6 > in my test message and 63.246.31.248 in the message from Declude's mailing > list. > > Since my Comcast IP address is not listed in my SPF string, it failed > Declude's SPF test. > > So what is the problem here? Is this a flaw in how SmarterMail lists its > hops? Should it be showing the Comcast IP address as the final hop, or > should it be showing my mail server? > > Since it is showing the Comcast address, SPF fails. The only way to get > around this is to end the SPF string with "?all", but if I'm going to do > that, I might as well not use SPF at all. > > Gary > > > Original Message > > From: "Michael Thomas - Mathbox" <[EMAIL PROTECTED]> > > Sent: Friday, February 16, 2007 3:47 PM > > To: declude.junkmail@declude.com > > Subject: RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > > > Gary, > > > > Your logic is incorrect. SPF is a check made by the destination mail > server > > (possibly my mail server) against the sending mail server (your mail > > server). Your users authenticate to your mail server, then submit a > message > > to your mail server for delivery by your mail server to the remote mail > > server. So, the remote mail server (possibly my mail server) would check > the > > SPF to determine if your mail server was listed as a source for the domain > > of the sending email address. > > > > Michael Thomas > > Mathbox > > 978-683-6718 > > 1-877-MATHBOX (Toll Free) > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > > Behalf Of Gary Steiner > > > Sent: Friday, February 16,
RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question
Gary, I guess, I should have asked this earlier, but you mentioned authenticated users, which is the other side of the coin. Are you testing SPF for outgoing mail? If so, why? Is it possible to send email from your mail server without authenticating? If none of that was pertinent, continue on == At your mail server, in those three received headers from my message, the only valid SPF check is on the following header: Received: from smtp.declude.com [63.246.31.248] by mail.plusultraweb.com with SMTP; Fri, 16 Feb 2007 15:46:48 -0500 Note that at this point, the email is from declude.junkmail@declude.com and the sending server is smtp.declude.com. The above header was added by your mail server. The SPF check on your mail server should be "Does the declude.com SPF indicate that mail from declude.com (in this case declude.junkmail@declude.com) can be sent by smtp.declude.com". As regards SPF, checking any deeper in the received lines makes no sense and is an invalid test. Why? Because at this point, the email is from declude.junkmail@declude.com and I doubt very much if the declude.com SPF record has mail.mathbox.com as a valid SMTP source for mail from declude.com. == The previous header entry (time and motion wise) was the received header for the transmission of the message from my mail server to the declude mail server: Received: from mail.mathbox.com [63.150.236.14] by smtp.declude.com with SMTP; Fri, 16 Feb 2007 15:31:18 -0500 The declude mail server should have performed a SPF check for mail from [EMAIL PROTECTED] being sent from mail.mathbox.com. === If for example, you had an SMTP proxy or a gateway in front of your mail server, then all of the above logic starts to break down. For those situations, you could use IPBYPASS and I suppose HOP. You chose a very good example. List mail is a perfectly good example of why you cannot run SPF against the entire chain of received headers. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Gary Steiner > Sent: Friday, February 16, 2007 4:10 PM > To: declude.junkmail@declude.com > Subject: RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > Let me give you my case. For this example I used my home > Comcast connection to send an email using Outlook and > authentication. My server uses Declude and SmarterMail. The > header of the received message shows one IP address in a > single Received line: > > Received: from c-67-189-34-6.hsd1.or.comcast.net > [67.189.34.6] by mail.plusultraweb.com with SMTP; >Fri, 16 Feb 2007 15:43:21 -0500 > > Michael's message via Declude's mailing list had three Received lines: > > Received: from smtp.declude.com [63.246.31.248] by > mail.plusultraweb.com with SMTP; >Fri, 16 Feb 2007 15:46:48 -0500 > Received: from mail.mathbox.com [63.150.236.14] by > smtp.declude.com with SMTP; >Fri, 16 Feb 2007 15:31:18 -0500 > Received: from mikesplace [63.150.236.3] by mail.mathbox.com > with ESMTP > (SMTPD-8.22) id A48F027C; Fri, 16 Feb 2007 15:31:11 -0500 > > In both messages Declude made checks versus the last hop only > (67.189.34.6 in my test message and 63.246.31.248 in the > message from Declude's mailing list. > > Since my Comcast IP address is not listed in my SPF string, > it failed Declude's SPF test. > > So what is the problem here? Is this a flaw in how > SmarterMail lists its hops? Should it be showing the Comcast > IP address as the final hop, or should it be showing my mail server? > > Since it is showing the Comcast address, SPF fails. The only > way to get around this is to end the SPF string with "?all", > but if I'm going to do that, I might as well not use SPF at all. > > Gary > > > Original Message ---- > > From: "Michael Thomas - Mathbox" <[EMAIL PROTECTED]> > > Sent: Friday, February 16, 2007 3:47 PM > > To: declude.junkmail@declude.com > > Subject: RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF > record question > > > > Gary, > > > > Your logic is incorrect. SPF is a check made by the > destination mail server > > (possibly my mail server) against the sending mail server (your mail > > server). Your users authenticate to your mail server, then > submit a message > > to your mail server for delivery by your mail server to the > remote mail > > server. So, the remote mail server (possibly my mail > server) would check the > > SPF to determine if your mail server was listed as a source > for the domain > > of the sending email address. > > >
Re: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question
Whitelisting SMTP Auth is the key here. Since you connect with a userID/PW to your mail server, Whitelisting connections done through SMTP AUTH bypasses Declude filtering. Darin. - Original Message - From: "Gary Steiner" <[EMAIL PROTECTED]> To: Sent: Friday, February 16, 2007 4:10 PM Subject: RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question Let me give you my case. For this example I used my home Comcast connection to send an email using Outlook and authentication. My server uses Declude and SmarterMail. The header of the received message shows one IP address in a single Received line: Received: from c-67-189-34-6.hsd1.or.comcast.net [67.189.34.6] by mail.plusultraweb.com with SMTP; Fri, 16 Feb 2007 15:43:21 -0500 Michael's message via Declude's mailing list had three Received lines: Received: from smtp.declude.com [63.246.31.248] by mail.plusultraweb.com with SMTP; Fri, 16 Feb 2007 15:46:48 -0500 Received: from mail.mathbox.com [63.150.236.14] by smtp.declude.com with SMTP; Fri, 16 Feb 2007 15:31:18 -0500 Received: from mikesplace [63.150.236.3] by mail.mathbox.com with ESMTP (SMTPD-8.22) id A48F027C; Fri, 16 Feb 2007 15:31:11 -0500 In both messages Declude made checks versus the last hop only (67.189.34.6 in my test message and 63.246.31.248 in the message from Declude's mailing list. Since my Comcast IP address is not listed in my SPF string, it failed Declude's SPF test. So what is the problem here? Is this a flaw in how SmarterMail lists its hops? Should it be showing the Comcast IP address as the final hop, or should it be showing my mail server? Since it is showing the Comcast address, SPF fails. The only way to get around this is to end the SPF string with "?all", but if I'm going to do that, I might as well not use SPF at all. Gary Original Message > From: "Michael Thomas - Mathbox" <[EMAIL PROTECTED]> > Sent: Friday, February 16, 2007 3:47 PM > To: declude.junkmail@declude.com > Subject: RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > Gary, > > Your logic is incorrect. SPF is a check made by the destination mail server > (possibly my mail server) against the sending mail server (your mail > server). Your users authenticate to your mail server, then submit a message > to your mail server for delivery by your mail server to the remote mail > server. So, the remote mail server (possibly my mail server) would check the > SPF to determine if your mail server was listed as a source for the domain > of the sending email address. > > Michael Thomas > Mathbox > 978-683-6718 > 1-877-MATHBOX (Toll Free) > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Gary Steiner > > Sent: Friday, February 16, 2007 2:56 PM > > To: declude.junkmail@declude.com > > Subject: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > > > I have a question to follow this subject. If users have > > Outlook and they are sending email fromm home or whereever > > using authentication, then the IP that shows up in the header > > will be their home connection. That being the case, unless > > your users are strictly using webmail, your SPF record should > > show no enforcement otherwise all the non-webmail messages > > will get blocked. To me this indicates that SPF doesn't help > > you if your users are not using webmail. Is this correct? > > > > Gary > > > > > > > > Original Message > > > From: "Darin Cox" <[EMAIL PROTECTED]> > > > Sent: Wednesday, February 07, 2007 4:33 PM > > > To: declude.junkmail@declude.com > > > Subject: Re: [Declude.JunkMail] OT: SPF record question > > > > > > If your MX and A records are also in the 216.15.92.0/25 > > network, then you > > > don't need to specify the "a" and "mx" parameters, so you > > could simplify to > > > > > > No enforcement, other hosts may send mail for the domain > > > "v=spf1 ip4:216.15.92.0/25 ?all" > > > > > > Soft fail if policy violated. Filters may or may not block > > on soft fail. > > > "v=spf1 ip4:216.15.92.0/25 ~all" > > > > > > > > > Hard fail if policy violated. Filters should block on hard fail. > > > "v=spf1 ip4:216.15.92.0/25 -all" > > > > > > However, if you send from an MX or A record (web server) > > that is not in the > > > 216.15.92.0/25 subnet then you may need those. > > > > > > If you use a soft or hard fail policy, it's very important &
RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question
Let me give you my case. For this example I used my home Comcast connection to send an email using Outlook and authentication. My server uses Declude and SmarterMail. The header of the received message shows one IP address in a single Received line: Received: from c-67-189-34-6.hsd1.or.comcast.net [67.189.34.6] by mail.plusultraweb.com with SMTP; Fri, 16 Feb 2007 15:43:21 -0500 Michael's message via Declude's mailing list had three Received lines: Received: from smtp.declude.com [63.246.31.248] by mail.plusultraweb.com with SMTP; Fri, 16 Feb 2007 15:46:48 -0500 Received: from mail.mathbox.com [63.150.236.14] by smtp.declude.com with SMTP; Fri, 16 Feb 2007 15:31:18 -0500 Received: from mikesplace [63.150.236.3] by mail.mathbox.com with ESMTP (SMTPD-8.22) id A48F027C; Fri, 16 Feb 2007 15:31:11 -0500 In both messages Declude made checks versus the last hop only (67.189.34.6 in my test message and 63.246.31.248 in the message from Declude's mailing list. Since my Comcast IP address is not listed in my SPF string, it failed Declude's SPF test. So what is the problem here? Is this a flaw in how SmarterMail lists its hops? Should it be showing the Comcast IP address as the final hop, or should it be showing my mail server? Since it is showing the Comcast address, SPF fails. The only way to get around this is to end the SPF string with "?all", but if I'm going to do that, I might as well not use SPF at all. Gary Original Message > From: "Michael Thomas - Mathbox" <[EMAIL PROTECTED]> > Sent: Friday, February 16, 2007 3:47 PM > To: declude.junkmail@declude.com > Subject: RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > Gary, > > Your logic is incorrect. SPF is a check made by the destination mail server > (possibly my mail server) against the sending mail server (your mail > server). Your users authenticate to your mail server, then submit a message > to your mail server for delivery by your mail server to the remote mail > server. So, the remote mail server (possibly my mail server) would check the > SPF to determine if your mail server was listed as a source for the domain > of the sending email address. > > Michael Thomas > Mathbox > 978-683-6718 > 1-877-MATHBOX (Toll Free) > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Gary Steiner > > Sent: Friday, February 16, 2007 2:56 PM > > To: declude.junkmail@declude.com > > Subject: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > > > I have a question to follow this subject. If users have > > Outlook and they are sending email fromm home or whereever > > using authentication, then the IP that shows up in the header > > will be their home connection. That being the case, unless > > your users are strictly using webmail, your SPF record should > > show no enforcement otherwise all the non-webmail messages > > will get blocked. To me this indicates that SPF doesn't help > > you if your users are not using webmail. Is this correct? > > > > Gary > > > > > > > > Original Message > > > From: "Darin Cox" <[EMAIL PROTECTED]> > > > Sent: Wednesday, February 07, 2007 4:33 PM > > > To: declude.junkmail@declude.com > > > Subject: Re: [Declude.JunkMail] OT: SPF record question > > > > > > If your MX and A records are also in the 216.15.92.0/25 > > network, then you > > > don't need to specify the "a" and "mx" parameters, so you > > could simplify to > > > > > > No enforcement, other hosts may send mail for the domain > > > "v=spf1 ip4:216.15.92.0/25 ?all" > > > > > > Soft fail if policy violated. Filters may or may not block > > on soft fail. > > > "v=spf1 ip4:216.15.92.0/25 ~all" > > > > > > > > > Hard fail if policy violated. Filters should block on hard fail. > > > "v=spf1 ip4:216.15.92.0/25 -all" > > > > > > However, if you send from an MX or A record (web server) > > that is not in the > > > 216.15.92.0/25 subnet then you may need those. > > > > > > If you use a soft or hard fail policy, it's very important > > that you identify > > > _all_ sources of outbound mail for the domain, including > > all mail servers, > > > marketing mail engines, webservers, external hosts, etc. > > Otherwise you're > > > liable to have mail blocked as a result of your policy. > > I've
RE: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question
Gary, Your logic is incorrect. SPF is a check made by the destination mail server (possibly my mail server) against the sending mail server (your mail server). Your users authenticate to your mail server, then submit a message to your mail server for delivery by your mail server to the remote mail server. So, the remote mail server (possibly my mail server) would check the SPF to determine if your mail server was listed as a source for the domain of the sending email address. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Gary Steiner > Sent: Friday, February 16, 2007 2:56 PM > To: declude.junkmail@declude.com > Subject: SPAM-WARN:Re: [Declude.JunkMail] OT: SPF record question > > I have a question to follow this subject. If users have > Outlook and they are sending email fromm home or whereever > using authentication, then the IP that shows up in the header > will be their home connection. That being the case, unless > your users are strictly using webmail, your SPF record should > show no enforcement otherwise all the non-webmail messages > will get blocked. To me this indicates that SPF doesn't help > you if your users are not using webmail. Is this correct? > > Gary > > > > Original Message > > From: "Darin Cox" <[EMAIL PROTECTED]> > > Sent: Wednesday, February 07, 2007 4:33 PM > > To: declude.junkmail@declude.com > > Subject: Re: [Declude.JunkMail] OT: SPF record question > > > > If your MX and A records are also in the 216.15.92.0/25 > network, then you > > don't need to specify the "a" and "mx" parameters, so you > could simplify to > > > > No enforcement, other hosts may send mail for the domain > > "v=spf1 ip4:216.15.92.0/25 ?all" > > > > Soft fail if policy violated. Filters may or may not block > on soft fail. > > "v=spf1 ip4:216.15.92.0/25 ~all" > > > > > > Hard fail if policy violated. Filters should block on hard fail. > > "v=spf1 ip4:216.15.92.0/25 -all" > > > > However, if you send from an MX or A record (web server) > that is not in the > > 216.15.92.0/25 subnet then you may need those. > > > > If you use a soft or hard fail policy, it's very important > that you identify > > _all_ sources of outbound mail for the domain, including > all mail servers, > > marketing mail engines, webservers, external hosts, etc. > Otherwise you're > > liable to have mail blocked as a result of your policy. > I've see this > > happen with a number of larger organizations, where they > have forgotten web > > servers with form-to-mail functions, marketing personnel sending out > > newsletters, or mobile users using ISP SMTP servers. > > > > Regarding your last three records, do you have subdomains > with MX records > > for direct.commarts.com, mail.commarts.com, and > smtp.commarts.com? I.e. do > > you receive mail to @direct.commarts.com, @mail.commarts.com, and > > @smtp.commarts.com addresses? If not, you don't need those records. > > > > Hope this helps, > > > > Darin. > > > > > > - Original Message - > > From: "Michael Hoyt" <[EMAIL PROTECTED]> > > To: "Declude JunkMail @declude.com" > > Sent: Wednesday, February 07, 2007 2:30 PM > > Subject: [Declude.JunkMail] OT: SPF record question > > > > > > Sorry for the re-posting but I forgot to add a Subject. > > > > I am finally getting my SPF records up but would like some > comments on > > whether I got it right. > > > > I would like to be able to send email from any IP address in my > > 216.15.92.0/25 network. Currently I have MX records for > mail.commarts.com > > (216.15.92.3) which is the only mail server that receives mail and > > direct.commarts.com (216.15.92.15) and smtp.commarts.com > (216.15.92.13). > > > > Using the Wizard at openspf.org I generated the following > SPF records: > > > > commarts.com. IN TXT "v=spf1 ip4:216.15.92.0/25 a mx ~all" > > direct.commarts.com. IN TXT "v=spf1 a -all" > > mail.commarts.com. IN TXT "v=spf1 a -all" > > smtp.commarts.com. IN TXT "v=spf1 a -all" > > > > After reading page 15 of the Whitepaper pertaining to the > ~all,-all or ?all > > part of the text in the first record my question is: If I > know that ALL > > email from my domain will originate from
Re[2]: [Declude.JunkMail] OT: SPF record question
> To me this indicates that SPF doesn't help you if your users are not > using webmail. Is this correct? No, the connecting IP seen by remote servers will still be the last hop on your network, not the authenticating IP that submitted the mail. While this is thus an irrelevant concern for remote mail, it is true that you must exempt authenticated sessions from *your own* SPF lookups, or else you will reject your own users. You do this either by (a) turning on such an exemption in your MTA for the primary port, (b) having users submit through an authenticated-only port and/or different authenticated-only MTA that doesn't do any SPF checks, or, least desirable, (c) using a spoofed internal SPF TXT record for your own domain that has a looser policy. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: SPF record question
I have a question to follow this subject. If users have Outlook and they are sending email fromm home or whereever using authentication, then the IP that shows up in the header will be their home connection. That being the case, unless your users are strictly using webmail, your SPF record should show no enforcement otherwise all the non-webmail messages will get blocked. To me this indicates that SPF doesn't help you if your users are not using webmail. Is this correct? Gary Original Message > From: "Darin Cox" <[EMAIL PROTECTED]> > Sent: Wednesday, February 07, 2007 4:33 PM > To: declude.junkmail@declude.com > Subject: Re: [Declude.JunkMail] OT: SPF record question > > If your MX and A records are also in the 216.15.92.0/25 network, then you > don't need to specify the "a" and "mx" parameters, so you could simplify to > > No enforcement, other hosts may send mail for the domain > "v=spf1 ip4:216.15.92.0/25 ?all" > > Soft fail if policy violated. Filters may or may not block on soft fail. > "v=spf1 ip4:216.15.92.0/25 ~all" > > > Hard fail if policy violated. Filters should block on hard fail. > "v=spf1 ip4:216.15.92.0/25 -all" > > However, if you send from an MX or A record (web server) that is not in the > 216.15.92.0/25 subnet then you may need those. > > If you use a soft or hard fail policy, it's very important that you identify > _all_ sources of outbound mail for the domain, including all mail servers, > marketing mail engines, webservers, external hosts, etc. Otherwise you're > liable to have mail blocked as a result of your policy. I've see this > happen with a number of larger organizations, where they have forgotten web > servers with form-to-mail functions, marketing personnel sending out > newsletters, or mobile users using ISP SMTP servers. > > Regarding your last three records, do you have subdomains with MX records > for direct.commarts.com, mail.commarts.com, and smtp.commarts.com? I.e. do > you receive mail to @direct.commarts.com, @mail.commarts.com, and > @smtp.commarts.com addresses? If not, you don't need those records. > > Hope this helps, > > Darin. > > > - Original Message - > From: "Michael Hoyt" <[EMAIL PROTECTED]> > To: "Declude JunkMail @declude.com" > Sent: Wednesday, February 07, 2007 2:30 PM > Subject: [Declude.JunkMail] OT: SPF record question > > > Sorry for the re-posting but I forgot to add a Subject. > > I am finally getting my SPF records up but would like some comments on > whether I got it right. > > I would like to be able to send email from any IP address in my > 216.15.92.0/25 network. Currently I have MX records for mail.commarts.com > (216.15.92.3) which is the only mail server that receives mail and > direct.commarts.com (216.15.92.15) and smtp.commarts.com (216.15.92.13). > > Using the Wizard at openspf.org I generated the following SPF records: > > commarts.com. IN TXT "v=spf1 ip4:216.15.92.0/25 a mx ~all" > direct.commarts.com. IN TXT "v=spf1 a -all" > mail.commarts.com. IN TXT "v=spf1 a -all" > smtp.commarts.com. IN TXT "v=spf1 a -all" > > After reading page 15 of the Whitepaper pertaining to the ~all,-all or ?all > part of the text in the first record my question is: If I know that ALL > email from my domain will originate from 216.15.92.0/25 should the text be > -all and not ~all? > > And my last question is are the three txt records mentioning my MX servers > necessary if I have 216.15.92.0/25 in the first record? > > Thank you in advance for any insight. > > -- > Michael Hoyt > > > Web Site: http://www.commarts.com > > > > > > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be found > at http://www.mail-archive.com. > > > > > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be found > at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: SPF record question
All email from my domains comes from 216.15.92.0/25 so hard fail "v=spf1 ip4:216.15.92.0/25 -all" is what I want. Thank you Darin. -- Michael Hoyt --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: SPF record question
If your MX and A records are also in the 216.15.92.0/25 network, then you don't need to specify the "a" and "mx" parameters, so you could simplify to No enforcement, other hosts may send mail for the domain "v=spf1 ip4:216.15.92.0/25 ?all" Soft fail if policy violated. Filters may or may not block on soft fail. "v=spf1 ip4:216.15.92.0/25 ~all" Hard fail if policy violated. Filters should block on hard fail. "v=spf1 ip4:216.15.92.0/25 -all" However, if you send from an MX or A record (web server) that is not in the 216.15.92.0/25 subnet then you may need those. If you use a soft or hard fail policy, it's very important that you identify _all_ sources of outbound mail for the domain, including all mail servers, marketing mail engines, webservers, external hosts, etc. Otherwise you're liable to have mail blocked as a result of your policy. I've see this happen with a number of larger organizations, where they have forgotten web servers with form-to-mail functions, marketing personnel sending out newsletters, or mobile users using ISP SMTP servers. Regarding your last three records, do you have subdomains with MX records for direct.commarts.com, mail.commarts.com, and smtp.commarts.com? I.e. do you receive mail to @direct.commarts.com, @mail.commarts.com, and @smtp.commarts.com addresses? If not, you don't need those records. Hope this helps, Darin. - Original Message - From: "Michael Hoyt" <[EMAIL PROTECTED]> To: "Declude JunkMail @declude.com" Sent: Wednesday, February 07, 2007 2:30 PM Subject: [Declude.JunkMail] OT: SPF record question Sorry for the re-posting but I forgot to add a Subject. I am finally getting my SPF records up but would like some comments on whether I got it right. I would like to be able to send email from any IP address in my 216.15.92.0/25 network. Currently I have MX records for mail.commarts.com (216.15.92.3) which is the only mail server that receives mail and direct.commarts.com (216.15.92.15) and smtp.commarts.com (216.15.92.13). Using the Wizard at openspf.org I generated the following SPF records: commarts.com. IN TXT "v=spf1 ip4:216.15.92.0/25 a mx ~all" direct.commarts.com. IN TXT "v=spf1 a -all" mail.commarts.com. IN TXT "v=spf1 a -all" smtp.commarts.com. IN TXT "v=spf1 a -all" After reading page 15 of the Whitepaper pertaining to the ~all,-all or ?all part of the text in the first record my question is: If I know that ALL email from my domain will originate from 216.15.92.0/25 should the text be -all and not ~all? And my last question is are the three txt records mentioning my MX servers necessary if I have 216.15.92.0/25 in the first record? Thank you in advance for any insight. -- Michael Hoyt Web Site: http://www.commarts.com --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] OT: SPF record question
Sorry for the re-posting but I forgot to add a Subject. I am finally getting my SPF records up but would like some comments on whether I got it right. I would like to be able to send email from any IP address in my 216.15.92.0/25 network. Currently I have MX records for mail.commarts.com (216.15.92.3) which is the only mail server that receives mail and direct.commarts.com (216.15.92.15) and smtp.commarts.com (216.15.92.13). Using the Wizard at openspf.org I generated the following SPF records: commarts.com. IN TXT "v=spf1 ip4:216.15.92.0/25 a mx ~all" direct.commarts.com. IN TXT "v=spf1 a -all" mail.commarts.com. IN TXT "v=spf1 a -all" smtp.commarts.com. IN TXT "v=spf1 a -all" After reading page 15 of the Whitepaper pertaining to the ~all,-all or ?all part of the text in the first record my question is: If I know that ALL email from my domain will originate from 216.15.92.0/25 should the text be -all and not ~all? And my last question is are the three txt records mentioning my MX servers necessary if I have 216.15.92.0/25 in the first record? Thank you in advance for any insight. -- Michael Hoyt Web Site: http://www.commarts.com --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
