Having only just worked out SRS for myself (I *think*), I've just
written the following SRS page on the wiki.
Without judgement for the finer points of literary value or technical
exactitude (it's been a loooooooooong week), have I at least got the
gist of it correct?
TIA,
Wechsler
SenderPermittedFrom/SenderRewritingScheme
-----------------------------------------
For full details, see the leaflets and draft RFC at
http://spf.pobox.com/srs.html
For an overview, read on (but note that this is not intended to be a
complete explanation):
SRS (Sender Rewriting Scheme) is a method of encapsulating a sequence of
email addresses into one string that conforms to the definition of
"Sender" for the purposes of an SMTP transaction. That list of addresses
comprises the "delivery route" of the message so far, one stage of the
route being added for each server that "re-originates" the message.
Re-origination occurs when a server re-transmits a message based on data
held on that server (ie not globally available or deducible from MX
records etc), such as a MailingList, DotForward or EtcAliases system.
It is not considered to occur when a server forwards a message to
another in a predetermined chain, according to MX records or a SmartHost
configuration.
To calculate SPF compliance at each stage, the last hop in the route can
be checked for sender address / IP compatability in the normal SPF
fashion, as the SRS-rewritten sender will be a legal email address at
the last SMTP host.
Should a bounce occur, it will be flagged as such and be sent back down
the source chain in order (reducing the address sequence as it goes)
until it reaches the originator. Note that this is the key change from
current practice, where bounces are sent directly to the originator.
Here a potential attack against SPF occurs; false chain-data could force
SRS-compliant SMTP servers in the bounce chain to send messages via
arbitrary routes to arbitrary recipients. SRS defeats this by allowing
SMTP servers to add a 'cookie' into the address chain, and locally store
the association between this cookie and the address chain or last step
in the chain. Should it receive a bounce, it can then examine the cookie
in that bounce and decide whether it saw that message in its outbound
journey. If not it can refuse to pass on the bounce. Individual SMTP
servers can decide whether or not to use this cookie scheme, as global
policy or on a per-message basis.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
written the following SRS page on the wiki.
Without judgement for the finer points of literary value or technical
exactitude (it's been a loooooooooong week), have I at least got the
gist of it correct?
TIA,
Wechsler
SenderPermittedFrom/SenderRewritingScheme
-----------------------------------------
For full details, see the leaflets and draft RFC at
http://spf.pobox.com/srs.html
For an overview, read on (but note that this is not intended to be a
complete explanation):
SRS (Sender Rewriting Scheme) is a method of encapsulating a sequence of
email addresses into one string that conforms to the definition of
"Sender" for the purposes of an SMTP transaction. That list of addresses
comprises the "delivery route" of the message so far, one stage of the
route being added for each server that "re-originates" the message.
Re-origination occurs when a server re-transmits a message based on data
held on that server (ie not globally available or deducible from MX
records etc), such as a MailingList, DotForward or EtcAliases system.
It is not considered to occur when a server forwards a message to
another in a predetermined chain, according to MX records or a SmartHost
configuration.
To calculate SPF compliance at each stage, the last hop in the route can
be checked for sender address / IP compatability in the normal SPF
fashion, as the SRS-rewritten sender will be a legal email address at
the last SMTP host.
Should a bounce occur, it will be flagged as such and be sent back down
the source chain in order (reducing the address sequence as it goes)
until it reaches the originator. Note that this is the key change from
current practice, where bounces are sent directly to the originator.
Here a potential attack against SPF occurs; false chain-data could force
SRS-compliant SMTP servers in the bounce chain to send messages via
arbitrary routes to arbitrary recipients. SRS defeats this by allowing
SMTP servers to add a 'cookie' into the address chain, and locally store
the association between this cookie and the address chain or last step
in the chain. Should it receive a bounce, it can then examine the cookie
in that bounce and decide whether it saw that message in its outbound
journey. If not it can refuse to pass on the bounce. Individual SMTP
servers can decide whether or not to use this cookie scheme, as global
policy or on a per-message basis.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h