Hi,
SRS was created to try to overcome a perceived problem with SPF.
That problem being that SPF cannot reliably assess mail that has
passed through a forwarder.
SRS addresses this problem by requiring the forwarder to rewrite the
sender address.
Some people are unhappy with this solution.
One way to describe the basis for this unhappyiness is that requiring
a forwarder to do something is simply not possible. I can control my
own mail server. I cannot control anyone else's.
For this reason, I think there needs to be a solution to the
forwarder problem that each party can independently enact to help be
sure that mail gets through.
The forwarder can use SRS on mail that passes through and thereby
make the mail more likely to be recieved.
The original sensed can (possibly) use universal SRS to authenticate
themselves as sender which might help their mail get through (if
recipients that implement SPF are willing to check universal SRS as
well).
But what can the recipient do? I.e. what can I do the make sure that
mail forwarded to users at my site get through, but that still allows
me to reject lots of mail based on SPF checks.
One thing that I have mentioned is to have local users register any
aliases that might be sending them mail, and to allow any mail to
them from authorised senders for that domain.
But this solution has real problems as keeping this database uptodate
and working would undoubtedly be an unpleasant overhead.
Another solution that recently occurred to me is to use recipient
rewriting. It would work like this:
When someone wants to set up a forwarder somewhere that forwards to
their account on my mailserver, they ask for a signed address (using
some local setuid program or a webpage that authenticates them or
similar).
This address looks something like:
RRS+HHHH+forwarderdomain+forwarderlocalpart+locallocalpart@domain
where the HHHH is a crypto HASH of some secret with the rest of the
address.
If I receive an address like that, I check that the HHHH is
correct, and if it is, I use forwarderlocalpart@forwarderdomain as
the responsible sender for an SPF check. The result of that check
is used as input to my local policy for rejecting or accepting
email.
If the mail is accepted, it is sent on to locallocalpart@domain of
course.
This approach still requires my customers to be aware of their
forwarders and to take local action with respect to them, but it
means that I don't have to maintain a database.
Having a range of mechanisms that I can use depending on whether I am
acting as a sender, and recipient, or a forwarder means that I can
maximise the chance of my customers mail getting through, both
incoming and outgoing, without depending on particular behaviour of
other sites. I think this is a win.
NeilBrown
SRS was created to try to overcome a perceived problem with SPF.
That problem being that SPF cannot reliably assess mail that has
passed through a forwarder.
SRS addresses this problem by requiring the forwarder to rewrite the
sender address.
Some people are unhappy with this solution.
One way to describe the basis for this unhappyiness is that requiring
a forwarder to do something is simply not possible. I can control my
own mail server. I cannot control anyone else's.
For this reason, I think there needs to be a solution to the
forwarder problem that each party can independently enact to help be
sure that mail gets through.
The forwarder can use SRS on mail that passes through and thereby
make the mail more likely to be recieved.
The original sensed can (possibly) use universal SRS to authenticate
themselves as sender which might help their mail get through (if
recipients that implement SPF are willing to check universal SRS as
well).
But what can the recipient do? I.e. what can I do the make sure that
mail forwarded to users at my site get through, but that still allows
me to reject lots of mail based on SPF checks.
One thing that I have mentioned is to have local users register any
aliases that might be sending them mail, and to allow any mail to
them from authorised senders for that domain.
But this solution has real problems as keeping this database uptodate
and working would undoubtedly be an unpleasant overhead.
Another solution that recently occurred to me is to use recipient
rewriting. It would work like this:
When someone wants to set up a forwarder somewhere that forwards to
their account on my mailserver, they ask for a signed address (using
some local setuid program or a webpage that authenticates them or
similar).
This address looks something like:
RRS+HHHH+forwarderdomain+forwarderlocalpart+locallocalpart@domain
where the HHHH is a crypto HASH of some secret with the rest of the
address.
If I receive an address like that, I check that the HHHH is
correct, and if it is, I use forwarderlocalpart@forwarderdomain as
the responsible sender for an SPF check. The result of that check
is used as input to my local policy for rejecting or accepting
email.
If the mail is accepted, it is sent on to locallocalpart@domain of
course.
This approach still requires my customers to be aware of their
forwarders and to take local action with respect to them, but it
means that I don't have to maintain a database.
Having a range of mechanisms that I can use depending on whether I am
acting as a sender, and recipient, or a forwarder means that I can
maximise the chance of my customers mail getting through, both
incoming and outgoing, without depending on particular behaviour of
other sites. I think this is a win.
NeilBrown