Re: SRS/SPF Help Needed
"David Sowder" <[email protected]> Mon, 10 Jul 2006 14:02:56 -0500
| Newsgroups | gmane.mail.spam.srs.general |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_15380_7077493.1152558176062 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/10/06, Andy Shellam <[email protected]> wrote: > > David and Robert, > > That's fantastic - a perfect explanation - thanks a million guys :) I > wasn't getting the full illustration from the on-line docs. > > With regard to your comment Dave about dealing with bounced forwarded > messages, I was having a quick read through the docs of SPF and SRS, and > it appears that in SPFv1, if the sending MAIL FROM header is <> (i.e. a > bounce message), the receiving MX looks up the SPF record from the EHLO > server name given. So in your example situation, if Yes, it looks up the HELO/EHLO if there is no domain in the MAIL FROM. finaldestination.com had to bounce a message received from sending.com > via publicdomain.com, SRS would have re-written the sender to something > like sender#[email protected]. Finaldestination.com would announce itself as (for example) mx1.finaldestination.com. > Publicdomain.com would look up the SPF for mx1.finaldestination.com. > SRS at publicdomain.com would then unwrap the To: address to > [email protected], and forward it back to sending.com (sending.com > would look up SPF for the given EHLO name (e.g. mx1.publicdomain.com) as > there is no From: address.) > > Right? I believe you have it right. The only part I'm slightly fuzzy on is the SRS part, but I believe it's correct. "It strikes me that if you're not actually going to use different server > machines when your clients add their own domain names, and assuming you > have your DNS TXT record set up correctly, you won't be having broken > forwarding issues at all." > > I had wondered about this actually. Obviously if I have control of the > DNS, there's no problem, but if you take the situation: > > A client has his own domain name: "external.com." He points his MX > records to my servers, and sends all outgoing e-mails through my servers > (announced as exchange.mailnetwork.co.uk and dns.mailnetwork.co.uk.) If > the client does not know about SPF, and/or doesn't have access to his > DNS to add TXT records - he sends an e-mail to, for example, > publicdomain.com. The MX at publicdomain.com looks up SPF for > "external.com", however because there are no SPF records, the message > gets rejected (or treated as a possible forgery.) Therefore SRS would > be needed to rewrite the address to have come from mailnetwork.co.uk. To be clear, an MTA checking SPF should not reject on no SPF record (at least not until SPF is pretty much ubiquitous), but rather rely on other mechanisms to check for forgery. SRS should probably be used on all forwarded messages, regardless of the original sender having an SPF record or not. I'm unclear of what you're saying with the last sentence: "Therefore SRS would..." I have this situation with my andycc.net domain, in that andycc.net is > my domain but the mailservers are on mailnetwork.co.uk - however I have > the bonus that I can modify the DNS :) If mailnetwork.co.uk is also your server, you should whitelist any MX hosts for mailnetwork.co.uk. SPF is not intended to check messages sent from an MX host for a domain to the actual server for that domain. For example, if I setup example.com to have three servers: mx1.example.com, mx2.example.com and realserver.example.com, realserver.example.com should whitelist all messages coming from mx1.example.com and mx2.example.com for SPF purposes (i.e. on realserver.example.com, if the connection is coming from mx1.example.com or mx2.example.com, an SPF record shouldn't be checked because mx1 or mx2 should have already done that). Neither mx1.example.comnor mx2.example.com should use SRS when sending a message received for example.com to realserver.example.com since they're all under the same administrative control. If mx1.example.com and mx2.example.com are MX hosts for otherdomain.com and otherdomain.com is not run by the same people, then mx1 and mx2 are really forwarders that happen to be setup as MX hosts (because the entire domain is forwarded) and should use SRS. -- David R. Sowder University of Texas at Arlington Department of Modern Languages Language Acquisition Center Supervisor Work: [email protected] Personal: [email protected] Lists: [email protected] http://david.sowder.com/ ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[email protected] ------=_Part_15380_7077493.1152558176062 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/10/06, <b class="gmail_sendername">Andy Shellam</b> <<a href="mailto:[email protected]">[email protected]</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> David and Robert,<br><br>That's fantastic - a perfect explanation - thanks a million guys :) I<br>wasn't getting the full illustration from the on-line docs.<br><br>With regard to your comment Dave about dealing with bounced forwarded <br>messages, I was having a quick read through the docs of SPF and SRS, and<br>it appears that in SPFv1, if the sending MAIL FROM header is <> (i.e. a<br>bounce message), the receiving MX looks up the SPF record from the EHLO <br>server name given. So in your example situation, if</blockquote><div><br>Yes, it looks up the HELO/EHLO if there is no domain in the MAIL FROM.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <a href="http://finaldestination.com">finaldestination.com</a> had to bounce a message received from <a href="http://sending.com">sending.com</a><br>via <a href="http://publicdomain.com">publicdomain.com</a>, SRS would have re-written the sender to something <br>like <a href="mailto:sender#[email protected]">sender#[email protected]</a>. <a href="http://Finaldestination.com">Finaldestination.com</a> would</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> announce itself as (for example) <a href="http://mx1.finaldestination.com">mx1.finaldestination.com</a>.<br><a href="http://Publicdomain.com">Publicdomain.com</a> would look up the SPF for <a href="http://mx1.finaldestination.com"> mx1.finaldestination.com</a>.<br>SRS at <a href="http://publicdomain.com">publicdomain.com</a> would then unwrap the To: address to<br><a href="mailto:[email protected]">[email protected]</a>, and forward it back to <a href="http://sending.com"> sending.com</a> (<a href="http://sending.com">sending.com</a><br>would look up SPF for the given EHLO name (e.g. <a href="http://mx1.publicdomain.com">mx1.publicdomain.com</a>) as<br>there is no From: address.)<br><br>Right? </blockquote><div><br>I believe you have it right. The only part I'm slightly fuzzy on is the SRS part, but I believe it's correct.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> "It strikes me that if you're not actually going to use different server<br>machines when your clients add their own domain names, and assuming you<br>have your DNS TXT record set up correctly, you won't be having broken <br>forwarding issues at all."<br><br>I had wondered about this actually. Obviously if I have control of the<br>DNS, there's no problem, but if you take the situation:<br><br>A client has his own domain name: " <a href="http://external.com">external.com</a>." He points his MX<br>records to my servers, and sends all outgoing e-mails through my servers<br>(announced as <a href="http://exchange.mailnetwork.co.uk">exchange.mailnetwork.co.uk </a> and dns.mailnetwork.co.uk.) If<br>the client does not know about SPF, and/or doesn't have access to his<br>DNS to add TXT records - he sends an e-mail to, for example,<br><a href="http://publicdomain.com">publicdomain.com </a>. The MX at <a href="http://publicdomain.com">publicdomain.com</a> looks up SPF for<br>"<a href="http://external.com">external.com</a>", however because there are no SPF records, the message<br>gets rejected (or treated as a possible forgery.) Therefore SRS would <br>be needed to rewrite the address to have come from <a href="http://mailnetwork.co.uk">mailnetwork.co.uk</a>.</blockquote><div><br>To be clear, an MTA checking SPF should not reject on no SPF record (at least not until SPF is pretty much ubiquitous), but rather rely on other mechanisms to check for forgery. SRS should probably be used on all forwarded messages, regardless of the original sender having an SPF record or not. I'm unclear of what you're saying with the last sentence: "Therefore SRS would..." <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I have this situation with my <a href="http://andycc.net">andycc.net</a> domain, in that <a href="http://andycc.net">andycc.net</a> is<br>my domain but the mailservers are on <a href="http://mailnetwork.co.uk">mailnetwork.co.uk</a> - however I have<br>the bonus that I can modify the DNS :)</blockquote><div><br> If <a href="http://mailnetwork.co.uk">mailnetwork.co.uk</a> is also your server, you should whitelist any MX hosts for <a href="http://mailnetwork.co.uk">mailnetwork.co.uk</a>. SPF is not intended to check messages sent from an MX host for a domain to the actual server for that domain. <br><br>For example, if I setup <a href="http://example.com">example.com</a> to have three servers: <a href="http://mx1.example.com">mx1.example.com</a>, <a href="http://mx2.example.com">mx2.example.com</a> and <a href="http://realserver.example.com"> realserver.example.com</a>, <a href="http://realserver.example.com">realserver.example.com</a> should whitelist all messages coming from <a href="http://mx1.example.com">mx1.example.com</a> and <a href="http://mx2.example.com"> mx2.example.com</a> for SPF purposes (i.e. on <a href="http://realserver.example.com">realserver.example.com</a>, if the connection is coming from <a href="http://mx1.example.com">mx1.example.com</a> or <a href="http://mx2.example.com"> mx2.example.com</a>, an SPF record shouldn't be checked because mx1 or mx2 should have already done that). Neither <a href="http://mx1.example.com">mx1.example.com</a> nor <a href="http://mx2.example.com">mx2.example.com </a> should use SRS when sending a message received for <a href="http://example.com">example.com</a> to <a href="http://realserver.example.com">realserver.example.com</a> since they're all under the same administrative control. <br><br>If <a href="http://mx1.example.com">mx1.example.com</a> and <a href="http://mx2.example.com">mx2.example.com</a> are MX hosts for <a href="http://otherdomain.com">otherdomain.com</a> and <a href="http://otherdomain.com"> otherdomain.com</a> is not run by the same people, then mx1 and mx2 are really forwarders that happen to be setup as MX hosts (because the entire domain is forwarded) and should use SRS.<br></div></div><br>-- <br>David R. Sowder <br>University of Texas at Arlington<br>Department of Modern Languages<br>Language Acquisition Center Supervisor<br>Work: <a href="mailto:[email protected]">[email protected]</a><br>Personal: <a href="mailto:[email protected]">[email protected] </a><br>Lists: <a href="mailto:[email protected]">[email protected]</a><br><a href="http://david.sowder.com/">http://david.sowder.com/</a> <HR> To unsubscribe, change your address, or temporarily deactivate your subscription, please go to <A HREF="http://v2.listbox.com/member/[email protected]">http://v2.listbox.com/member/[email protected]</A> ------=_Part_15380_7077493.1152558176062--