Mailing List Archive

This is probably an oversimplified explanation but it should serve to
point you in the right direction.

SPF breaks mail forwarding. For example, sender@sending.com (IP address
1.2.3.4) sends an email to intended@publicdomain.com who actually picks up
his mail at its final destination
intendeds-real-acct@finaldestination.com. 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.

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.

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.

On Mon, 10 Jul 2006, Andy Shellam wrote:

> Date: Mon, 10 Jul 2006 11:56:58 +0100
> From: Andy Shellam <andy@andycc.net>
> Reply-To: srs-discuss@v2.listbox.com
> To: srs-discuss@v2.listbox.com
> 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. andy@mailnetwork.co.uk is an alias
> for andy@andycc.net) - 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 andy@mailnetwork.co.uk, the mail
> server will rewrite it as andy@andycc.net.
>
>
>
> 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/?listname=srs-discuss@v2.listbox.com

On 7/10/06, Robert Muchnick <hostmaster@xenterra.net> wrote:
>
> This is probably an oversimplified explanation but it should serve to
> point you in the right direction.
>
> SPF breaks mail forwarding. For example, sender@sending.com (IP address
> 1.2.3.4) sends an email to intended@publicdomain.com who actually picks up
> his mail at its final destination
> intendeds-real-acct@finaldestination.com. 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 <andy@andycc.net>
> > Reply-To: srs-discuss@v2.listbox.com
> > To: srs-discuss@v2.listbox.com
> > 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. andy@mailnetwork.co.uk is an
> alias
> > for andy@andycc.net) - 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 andy@mailnetwork.co.uk, the mail
> > server will rewrite it as andy@andycc.net.
> >
> >
> >
> > 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/?listname=srs-discuss@v2.listbox.com
>



--
David R. Sowder
University of Texas at Arlington
Department of Modern Languages
Language Acquisition Center Supervisor
Work: davids@uta.edu
Personal: david@sowder.com
Lists: davidrsowder@gmail.com
http://david.sowder.com/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

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
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#sending.com@publicdomain.com. 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
sender@sending.com, 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?

"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.

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 :)

Thanks again,

Andy


David Sowder wrote:
> On 7/10/06, *Robert Muchnick* <hostmaster@xenterra.net
> <mailto:hostmaster@xenterra.net>> wrote:
>
> This is probably an oversimplified explanation but it should serve to
> point you in the right direction.
>
> SPF breaks mail forwarding. For example, sender@sending.com
> <mailto:sender@sending.com> (IP address
> 1.2.3.4 <http://1.2.3.4>) sends an email to
> intended@publicdomain.com <mailto:intended@publicdomain.com> who
> actually picks up
> his mail at its final destination
> intendeds-real-acct@finaldestination.com
> <mailto:intendeds-real-acct@finaldestination.com>. So
> publicdomain.com <http://publicdomain.com> is a
> forwarder (as in virtusertable) to the machine
> finaldestination.com <http://finaldestination.com> .
>
> Without SRS, publicdomain.com <http://publicdomain.com> will try
> to forward the mail to
> finaldestination.com <http://finaldestination.com> while
> announcing the FROM IP address as 1.2.3.4 <http://1.2.3.4>,
> which SPF will reject because it doesn't jive with the IP for
> publicdomain.com <http://publicdomain.com>. That's the anti-SPAM
> aspect of SPF.
>
>
> finaldestination.com <http://finaldestination.com>'s MX host will see
> the client coming from publicdomain.com <http://publicdomain.com>'s IP
> address, which sending.com <http://sending.com> didn't likely
> authorize in the SPF record for sending.com <http://sending.com>.
> finaldestination.com <http://finaldestination.com>, when checking SPF
> records, will see the envelope MAIL FROM: header containing
> sending.com <http://sending.com> and lookup the SPF record for
> sending.com <http://sending.com> and check the clien'ts IP address
> (the IP address for publicdomain.com <http://publicdomain.com>) to see
> if sending.com <http://sending.com>'s SPF record authorizes that IP
> address to claim to be sending.com <http://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
> <http://publicdomain.com> didn't check the SPF record for sending.com
> <http://sending.com> before forwarding the message.
>
> To cure this and allow desired forwarding, SRS (on
> publicdomain.com <http://publicdomain.com>)
> rewrites the sender address (now seen as coming from
> publicdomain.com <http://publicdomain.com>) so
> that SPF on finaldestination.com <http://finaldestination.com>
> will accept the mail.
>
>
> SRS is intended to rewrite the envelope MAIL FROM (RFC821) to that of
> the forwarding sender ( publicdomain.com <http://publicdomain.com>)
> such that finaldestination.com <http://finaldestination.com>'s SPF
> check will be against the SPF record for publicdomain.com
> <http://publicdomain.com>, which presumably allows it's own IP address
> to send mail for publicdomain.com <http://publicdomain.com>. :) A
> downside to this approach is that you have to sort out how
> finaldestination.com <http://finaldestination.com> bouncing 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 <http://publicdomain.com> and finaldestination.com
> <http://finaldestination.com> are in the same administrative domain,
> but on separate servers, finaldestination should simply whitelist
> messages coming from publicdomain.com <http://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 <andy@andycc.net <mailto:andy@andycc.net>>
> > Reply-To: srs-discuss@v2.listbox.com
> <mailto:srs-discuss@v2.listbox.com>
> > To: srs-discuss@v2.listbox.com <mailto:srs-discuss@v2.listbox.com>
> > 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
> <http://mailnetwork.co.uk>, which has an SPF record,
> > authorising the machines exchange.mailnetwork.co.uk
> <http://exchange.mailnetwork.co.uk> ( 88.208.192.113
> <http://88.208.192.113>,
> > 88.208.192.114 <http://88.208.192.114>) and
> dns.mailnetwork.co.uk <http://dns.mailnetwork.co.uk>
> (84.18.200.160 <http://84.18.200.160>) to send mail from
> > mailnetwork.co.uk <http://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 <http://mailnetwork.co.uk>
> > and andycc.net <http://andycc.net> are currently the two
> most-used) as their sender addresses -
> > they are allowed incoming aliases (e.g. andy@mailnetwork.co.uk
> <mailto:andy@mailnetwork.co.uk> is an alias
> > for andy@andycc.net <mailto:andy@andycc.net>) - 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 andy@mailnetwork.co.uk
> <mailto:andy@mailnetwork.co.uk>, the mail
> > server will rewrite it as andy@andycc.net <mailto:andy@andycc.net>.
> >
> >
> >
> > 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 <http://Xenterra.net>
> 720-276-7917
>
> -------
> To unsubscribe, change your address, or temporarily deactivate
> your subscription,
> please go to
> http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
> <http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com>
>
>
>
>
> --
> David R. Sowder
> University of Texas at Arlington
> Department of Modern Languages
> Language Acquisition Center Supervisor
> Work: davids@uta.edu <mailto:davids@uta.edu>
> Personal: david@sowder.com <mailto:david@sowder.com>
> Lists: davidrsowder@gmail.com <mailto:davidrsowder@gmail.com>
> http://david.sowder.com/ <http://david.sowder.com/>
> ------------------------------------------------------------------------
> To unsubscribe, change your address, or temporarily deactivate your
> subscription, please go to
> http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
> !DSPAM:14,44b2913f34531536620633!

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Mon, 10 Jul 2006, Andy Shellam wrote:

<< >>

> 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

If the client was able to point his MX records to your servers, then he
has to some degree control over his DNS, even if it's to ask the sys admin
to make the modifications.

> - 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.

I don't think that's right. That would, in fact, be the very forgery that
SPF is designed to block and isn't the proper application of SRS. What
needs to be done for external.com, since we've established that the client
has some degree of control over his DNS (it's a necessity), is to use the
"include" parameter in the TXT record, something like this:

TXT "v=spf1 a mx include:mailnetwork.co.uk -all"

Then mailnetwork.co.uk is an "authorized" mail relay or MTA for
external.com.

--
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/?listname=srs-discuss@v2.listbox.com

On 7/10/06, Andy Shellam <andy@andycc.net> 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#sending.com@publicdomain.com. 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
> sender@sending.com, 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: davids@uta.edu
Personal: david@sowder.com
Lists: davidrsowder@gmail.com
http://david.sowder.com/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

"If the client was able to point his MX records to your servers, then he
has to some degree control over his DNS, even if it's to ask the sys
admin to make the modifications. "

True, but not all DNS providers allow clients to manage TXT records -
before I hosted my own DNS my old provider only allowed me to add A,
CNAME and MX records.

"I don't think that's right. That would, in fact, be the very forgery
that SPF is designed to block and isn't the proper application of SRS."

Surely though, that's the idea behind SRS, is that it rewrites messages
that are sent through a forwarding service to have come from the
forwarding service - in my situation, mailnetwork.co.uk is technically a
forwarding service for andycc.net (and in the previous example,
external.com). Therefore SRS on exchange.mailnetwork.co.uk would need
to rewrite messages from andycc.net to appear to have come from
mailnetwork.co.uk - so if a bounce is returned, it gets returned through
mailnetwork.co.uk, and subsequently translated back to andycc.net?

If a spammer sends an e-mail claiming to be from andycc.net, then
SPF-enabled MXs will fail it because I have mailnetwork.co.uk servers
authorised in the SPF. However, if the client "external.com" couldn't
add an SPF, then the SPF would fail - which would be right cos it's
forged. Whereas if a genuine mail had come through my servers, the
domain would have been written to have come from mailnetwork.co.uk and
therefore the SPF would succeed cos it'd be a mailnetwork.co.uk server
sending it.

Damn this takes some head-scratching!!

Andy

Robert Muchnick wrote:
> On Mon, 10 Jul 2006, Andy Shellam wrote:
>
> << >>
>
>> 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
>
> If the client was able to point his MX records to your servers, then
> he has to some degree control over his DNS, even if it's to ask the
> sys admin to make the modifications.
>
>> - 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.
>
> I don't think that's right. That would, in fact, be the very forgery
> that SPF is designed to block and isn't the proper application of SRS.
> What needs to be done for external.com, since we've established that
> the client has some degree of control over his DNS (it's a necessity),
> is to use the "include" parameter in the TXT record, something like this:
>
> TXT "v=spf1 a mx include:mailnetwork.co.uk -all"
>
> Then mailnetwork.co.uk is an "authorized" mail relay or MTA for
> external.com.
>

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Mon, 10 Jul 2006, Andy Shellam wrote:

<< >>
> Surely though, that's the idea behind SRS, is that it rewrites messages that
> are sent through a forwarding service to have come from the forwarding
> service - in my situation, mailnetwork.co.uk is technically a forwarding
> service for andycc.net (and in the previous example, external.com).
> Therefore SRS on exchange.mailnetwork.co.uk would need to rewrite messages
> from andycc.net to appear to have come from mailnetwork.co.uk - so if a
> bounce is returned, it gets returned through mailnetwork.co.uk, and
> subsequently translated back to andycc.net?

Yes, I think I misapprehended your earlier scenario. If mailnetwork.co.uk
is acting as a forwarding service, then I believe your usage of SRS there
would be correct for "external.com".

> Damn this takes some head-scratching!!

I'll second that; there isn't much simple about SPF/SRS but it's wonderful
technology.

--
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/?listname=srs-discuss@v2.listbox.com

On Mon, 10 Jul 2006, David Sowder wrote:

> > Publicdomain.com would look up the SPF for mx1.finaldestination.com.
> > SRS at publicdomain.com would then unwrap the To: address to
> > sender@sending.com, 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.

Since finaldestination.com is the one that configured publicdomain.com to
do the forwarding, a much simpler solution that SRS is to simply not check SPF
for mail coming from publicdomain.com. There is no point in check SPF for
that domain anyway, because unless publicdomain.com itself checks SPF
before forwarding, anyone can forge mail by forwarding through them -
with or without SRS at the forwarder.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

Stuart D. Gathman writes:
> Since finaldestination.com is the one that configured publicdomain.com to
> do the forwarding, a much simpler solution that SRS is to simply not check SPF
> for mail coming from publicdomain.com.

In real-life, finaldestination.com usually did NOT have any role in
configuring (or requesting) forwarding. It usually does not even know
the forwarding is occurring until something goes wrong.

Much of the point of SRS is to be a solution for forwarders that does
not require every case to be handled as a special case with some final
destination. As a forwarder, SRS enables me to get forwarded mail to
my users. As a final destination, SRS (at a forwarder) allows my
users to receive forwarded mail here without any intervention by me.

--
Dick St.Peters, stpeters@NetHeaven.com

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com

On Tue, 11 Jul 2006, Dick St.Peters wrote:

> Stuart D. Gathman writes:
> > Since finaldestination.com is the one that configured publicdomain.com to
> > do the forwarding, a much simpler solution that SRS is to simply not check SPF
> > for mail coming from publicdomain.com.
>
> In real-life, finaldestination.com usually did NOT have any role in
> configuring (or requesting) forwarding. It usually does not even know
> the forwarding is occurring until something goes wrong.

Translation:
In real-life, the administrators at finaldestination.com usually have
no clue what their users are configuring or requesting with regards
to forwarding. They can't blame the users either, because they don't provide
any mechanism (e.g. a web page or formal request for notification) for their
users to tell them about the forwarding. This wouldn't be a problem,
except these same administrators decided to start rejecting mail with
SPF fail without understanding what they were doing.

> Much of the point of SRS is to be a solution for forwarders that does
> not require every case to be handled as a special case with some final
> destination. As a forwarder, SRS enables me to get forwarded mail to
> my users. As a final destination, SRS (at a forwarder) allows my
> users to receive forwarded mail here without any intervention by me.

Yes, SRS is a reasonable workaround for clueless finaldestinations.
It even has a certain poetic justice when the SRS forwarder doesn't check
SPF and becomes an open conduit for forged mail - but I'm not sure
that helps SPF.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com