Re: SRS/SPF Help Needed
"David Sowder" <[email protected]> Mon, 10 Jul 2006 12:39:52 -0500
| Newsgroups | gmane.mail.spam.srs.general |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_12584_24726626.1152553192957 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/10/06, Robert Muchnick <[email protected]> wrote: > > This is probably an oversimplified explanation but it should serve to > point you in the right direction. > > SPF breaks mail forwarding. For example, [email protected] (IP address > 1.2.3.4) sends an email to [email protected] who actually picks up > his mail at its final destination > [email protected]. So publicdomain.com is a > forwarder (as in virtusertable) to the machine finaldestination.com. > > Without SRS, publicdomain.com will try to forward the mail to > finaldestination.com while announcing the FROM IP address as 1.2.3.4, > which SPF will reject because it doesn't jive with the IP for > publicdomain.com. That's the anti-SPAM aspect of SPF. finaldestination.com's MX host will see the client coming from publicdomain.com's IP address, which sending.com didn't likely authorize in the SPF record for sending.com. finaldestination.com, when checking SPF records, will see the envelope MAIL FROM: header containing sending.com and lookup the SPF record for sending.com and check the clien'ts IP address (the IP address for publicdomain.com) to see if sending.com's SPF record authorizes that IP address to claim to be sending.com in the envelope MAIL FROM (RFC821). SPF is not anti-spam; but rather anti-forgery. Note that forgery is still possible if publicdomain.com didn't check the SPF record for sending.com before forwarding the message. To cure this and allow desired forwarding, SRS (on publicdomain.com) > rewrites the sender address (now seen as coming from publicdomain.com) so > that SPF on finaldestination.com will accept the mail. SRS is intended to rewrite the envelope MAIL FROM (RFC821) to that of the forwarding sender (publicdomain.com) such that finaldestination.com's SPF check will be against the SPF record for publicdomain.com, which presumably allows it's own IP address to send mail for publicdomain.com. :) A downside to this approach is that you have to sort out how finaldestination.combouncing a forwarded message will be handled (rejected is a little easier to deal with). I'm pretty sure I got this right. The explanation is based on an actual > scenario I had to deal with about a year and a half ago and implementing > SRS as mentioned above was the only way to solve it. > > 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. If publicdomain.com and finaldestination.com are in the same administrative domain, but on separate servers, finaldestination should simply whitelist messages coming from publicdomain.com as a client. On Mon, 10 Jul 2006, Andy Shellam wrote: > > > Date: Mon, 10 Jul 2006 11:56:58 +0100 > > From: Andy Shellam <[email protected]> > > Reply-To: [email protected] > > To: [email protected] > > Subject: [srs-discuss] SRS/SPF Help Needed > > > > Hi, > > > > > > > > I need some advice off people who know about SRS! > > > > I'm designing a complete mail solution system based largely on > open-source > > products with custom tweaks, to support SPF, SRS and other validation > > schemes (such as DomainKeys) out-of-the-box. > > > > > > > > However, I'm having a little trouble under-standing the reasoning for > > requiring SRS. > > > > > > > > As an example: > > > > > > > > My company's domain is mailnetwork.co.uk, which has an SPF record, > > authorising the machines exchange.mailnetwork.co.uk (88.208.192.113, > > 88.208.192.114) and dns.mailnetwork.co.uk (84.18.200.160) to send mail > from > > mailnetwork.co.uk, and to fail any other servers that attempt to do so. > > > > > > > > Now, how does SRS come in to this? > > > > > > > > All my current users use one of our registered domains ( > mailnetwork.co.uk > > and andycc.net are currently the two most-used) as their sender > addresses - > > they are allowed incoming aliases (e.g. [email protected] is an > alias > > for [email protected]) - however, if a user tries to use an alias as the > > sender address it is rewritten to the alias' destination address - e.g. > if I > > tried to send using a From: address of [email protected], the mail > > server will rewrite it as [email protected]. > > > > > > > > When it gets off the ground, users will have the ability to add their > own > > domains to the system - I'm guessing in this case, the system will act > as a > > forwarder, and I'm thinking this is where SRS comes in, but I'm a tad > > confused how SPF breaks forwarding and the like!! > > > > > > > > Any advice/explanations would be appreciated! > > > -- > Robert Muchnick > Xenterra.net > 720-276-7917 > > ------- > To unsubscribe, change your address, or temporarily deactivate your > subscription, > please go to > http://v2.listbox.com/member/[email protected] > -- 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_12584_24726626.1152553192957 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/10/06, <b class="gmail_sendername">Robert Muchnick</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;"> This is probably an oversimplified explanation but it should serve to<br>point you in the right direction.<br><br>SPF breaks mail forwarding. For example, <a href="mailto:[email protected]">[email protected]</a> (IP address <br><a href="http://1.2.3.4">1.2.3.4</a>) sends an email to <a href="mailto:[email protected]">[email protected]</a> who actually picks up<br>his mail at its final destination<br><a href="mailto:[email protected]"> [email protected]</a>. So <a href="http://publicdomain.com">publicdomain.com</a> is a<br>forwarder (as in virtusertable) to the machine <a href="http://finaldestination.com">finaldestination.com</a> .<br><br>Without SRS, <a href="http://publicdomain.com">publicdomain.com</a> will try to forward the mail to<br><a href="http://finaldestination.com">finaldestination.com</a> while announcing the FROM IP address as <a href="http://1.2.3.4"> 1.2.3.4</a>,<br>which SPF will reject because it doesn't jive with the IP for<br><a href="http://publicdomain.com">publicdomain.com</a>. That's the anti-SPAM aspect of SPF.</blockquote><div><br><a href="http://finaldestination.com"> finaldestination.com</a>'s MX host will see the client coming from <a href="http://publicdomain.com">publicdomain.com</a>'s IP address, which <a href="http://sending.com">sending.com</a> didn't likely authorize in the SPF record for <a href="http://sending.com">sending.com</a>. <a href="http://finaldestination.com">finaldestination.com</a>, when checking SPF records, will see the envelope MAIL FROM: header containing <a href="http://sending.com">sending.com </a> and lookup the SPF record for <a href="http://sending.com">sending.com</a> and check the clien'ts IP address (the IP address for <a href="http://publicdomain.com">publicdomain.com</a>) to see if <a href="http://sending.com"> sending.com</a>'s SPF record authorizes that IP address to claim to be <a href="http://sending.com">sending.com</a> in the envelope MAIL FROM (RFC821). SPF is not anti-spam; but rather anti-forgery. Note that forgery is still possible if <a href="http://publicdomain.com">publicdomain.com</a> didn't check the SPF record for <a href="http://sending.com">sending.com</a> before forwarding the message.<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;"> To cure this and allow desired forwarding, SRS (on <a href="http://publicdomain.com">publicdomain.com</a>)<br>rewrites the sender address (now seen as coming from <a href="http://publicdomain.com">publicdomain.com</a>) so <br>that SPF on <a href="http://finaldestination.com">finaldestination.com</a> will accept the mail.</blockquote><div><br>SRS is intended to rewrite the envelope MAIL FROM (RFC821) to that of the forwarding sender (<a href="http://publicdomain.com"> publicdomain.com</a>) such that <a href="http://finaldestination.com">finaldestination.com</a>'s SPF check will be against the SPF record for <a href="http://publicdomain.com">publicdomain.com</a>, which presumably allows it's own IP address to send mail for <a href="http://publicdomain.com">publicdomain.com</a>. :) A downside to this approach is that you have to sort out how <a href="http://finaldestination.com">finaldestination.com</a> bouncing a forwarded message will be handled (rejected is a little easier to deal with). <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'm pretty sure I got this right. The explanation is based on an actual<br>scenario I had to deal with about a year and a half ago and implementing <br>SRS as mentioned above was the only way to solve it.<br><br>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.</blockquote><div><br>If <a href="http://publicdomain.com">publicdomain.com</a> and <a href="http://finaldestination.com">finaldestination.com</a> are in the same administrative domain, but on separate servers, finaldestination should simply whitelist messages coming from <a href="http://publicdomain.com">publicdomain.com</a> as a client. <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;">On Mon, 10 Jul 2006, Andy Shellam wrote: <br><br>> Date: Mon, 10 Jul 2006 11:56:58 +0100<br>> From: Andy Shellam <<a href="mailto:[email protected]">[email protected]</a>><br>> Reply-To: <a href="mailto:[email protected]">[email protected] </a><br>> To: <a href="mailto:[email protected]">[email protected]</a><br>> Subject: [srs-discuss] SRS/SPF Help Needed<br>><br>> Hi,<br>><br>><br>><br>> I need some advice off people who know about SRS! <br>><br>> I'm designing a complete mail solution system based largely on open-source<br>> products with custom tweaks, to support SPF, SRS and other validation<br>> schemes (such as DomainKeys) out-of-the-box. <br>><br>><br>><br>> However, I'm having a little trouble under-standing the reasoning for<br>> requiring SRS.<br>><br>><br>><br>> As an example:<br>><br>><br>><br>> My company's domain is <a href="http://mailnetwork.co.uk">mailnetwork.co.uk</a>, which has an SPF record,<br>> authorising the machines <a href="http://exchange.mailnetwork.co.uk">exchange.mailnetwork.co.uk</a> (<a href="http://88.208.192.113"> 88.208.192.113</a>,<br>> <a href="http://88.208.192.114">88.208.192.114</a>) and <a href="http://dns.mailnetwork.co.uk">dns.mailnetwork.co.uk</a> (<a href="http://84.18.200.160">84.18.200.160</a>) to send mail from<br> > <a href="http://mailnetwork.co.uk">mailnetwork.co.uk</a>, and to fail any other servers that attempt to do so.<br>><br>><br>><br>> Now, how does SRS come in to this?<br>><br>><br>><br>> All my current users use one of our registered domains ( <a href="http://mailnetwork.co.uk">mailnetwork.co.uk</a><br>> and <a href="http://andycc.net">andycc.net</a> are currently the two most-used) as their sender addresses -<br>> they are allowed incoming aliases (e.g. <a href="mailto:[email protected]">[email protected]</a> is an alias<br>> for <a href="mailto:[email protected]">[email protected]</a>) - however, if a user tries to use an alias as the<br>> sender address it is rewritten to the alias' destination address - e.g. if I<br>> tried to send using a From: address of <a href="mailto:[email protected]">[email protected]</a>, the mail<br>> server will rewrite it as <a href="mailto:[email protected]">[email protected]</a>. <br>><br>><br>><br>> When it gets off the ground, users will have the ability to add their own<br>> domains to the system - I'm guessing in this case, the system will act as a<br>> forwarder, and I'm thinking this is where SRS comes in, but I'm a tad <br>> confused how SPF breaks forwarding and the like!!<br>><br>><br>><br>> Any advice/explanations would be appreciated!<br><br><br>--<br>Robert Muchnick<br><a href="http://Xenterra.net">Xenterra.net</a><br> 720-276-7917<br><br>-------<br>To unsubscribe, change your address, or temporarily deactivate your subscription,<br>please go to <a href="http://v2.listbox.com/member/[email protected]">http://v2.listbox.com/member/[email protected] </a><br></blockquote></div><br><br clear="all"><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_12584_24726626.1152553192957--