-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Deutschmann wrote:
Still, this brings up one thing that I'd probably do if called to
forward. Rather than do either traditional forwarding or SRS, I'd adopt
a strategy I call "Sham SRS".
In Sham SRS, the MAIL FROM is rewritten to the same address for every
forward. The address cannot be the same as the forward address
(otherwise a bounce creates a mail-laser), but might be a trivial
modification.
So if <jane_roe(_at_)example(_dot_)com> writes to
<john_doe(_at_)example(_dot_)org> who is
really <joe_smith(_at_)example(_dot_)net>, the MAIL FROM on the second leg
might
be <forward-john_doe(_at_)example(_dot_)org>.
That's essentially the same as "database-backed SRS" as described in [1],
section 2.10. A "sham SRS" database would merely map origin addresses to
forwarder-domain addresses and vice versa.
Unlike SRS, this doesn't handle bounces. But we don't care. If
someone tries to mail from <> to <forward-john_doe(_at_)example(_dot_)org>, I
might 250 the RCPT TO: line merely to bypass any SAV nonsense. But at
DATA, the would be bouncer gets:
550 That was forwarded mail. It's NOT BOUNCABLE.
Heh, that's a novel idea! But handling bounces actually isn't a problem
as long as you have a _two-way_ mapping between origin addresses and
forwarder-domain addresses.
References:
1. http://www.libsrs2.org/srs/srs.pdf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHf5OpwL7PKlBZWjsRAh9CAJ9jXTjIpvjKonU+9f/dM/JyjZmPDACg4Jgv
U4tOjjV7xvc0CiqoeRluRj4=
=Vdf+
-----END PGP SIGNATURE-----
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=82150845-525fe5
Powered by Listbox: http://www.listbox.com