|
| 1) patch to sendmail so /etc/aliases will work transparently
| 2) SRS in .procmail (will probably involve a program |srsforward which calls
Mail::SRS)
| 3) |srsforward should also work inside a .forward environment
| 4) patch to other MTAs
| 5) /etc/aliases contains
|
| addr: "|/usr/sbin/sendmail -oi newaddress(_at_)example(_dot_)com"
|
| to send the msg with a new envelope-from; bounces will go back to the
| postmaster at your domain. In this setup, I think this is appropriate,
| since generally the failure case is that the forward address has changed
| and the aliases need to be updated.
|
The people on postfix-users argue that the original sender of the
message also deserves to know that their message didn't get through.
By default, an /etc/aliases bounce will go to the sender, unless you
create the owner-* address, in which case they'll go there instead.
The semantics of /etc/aliases forwarding were never well defined, so
there's all kinds of ambiguity.
So we have the following (possibly conflicting) requirements:
1) we want to preserve as much as possible of the original sender in the
rewritten address, because a final recipient may want to use it.
2) we want to respect the 64 char limit.
3) we want to insert a cookie to prevent open relaying.
4) we want to avoid the use of a database where possible,
because a database requires centralization and is a single point of
failure. SPF may stand for many things, but that shouldn't be one of
them.
Here are a few ideas I came up with. They show that a number of
workarounds are possible. I need somebody smarter to think of an even
better solution.
Plan A: breaking #2
At pobox, if a user enables SPF filtering, we will do SRS which
respects 1, 3, and 4, but may break 2 if the address is long.
foo(_at_)aol(_dot_)com -> bar(_at_)pobox(_dot_)com -> recipient
we rewrite to something like
bounce+foo#aol(_dot_)com-J0*dG7h8yzAwB=bar#pobox(_dot_)com(_at_)bounce(_dot_)pobox(_dot_)com
-> recipient
The special bounce.pobox.com domain handles SRS bounces exclusively.
Plan B: wildcard DNS
But what if we do this instead?
bounce+J0*dG7h8yzAwB(_at_)foo(_dot_)AT(_dot_)aol(_dot_)com(_dot_)VIA(_dot_)bar(_dot_)pobox(_dot_)com(_dot_)BY(_dot_)bounce(_dot_)pobox(_dot_)com
-> recipient
That keeps the local-part under 64, but may run afoul of total length
limits.
That would require that the special bounce domain have DNS
wildcarding.
Plan C: database
What if the incoming email address is already at
MAX-LOCALPART(_at_)MAX-DOMAIN? You can't preserve the whole thing; you have
to break 1 and 4 if you want to keep 2 and 3.
If the address is so long that it's not rewritable to one of the above
forms, you fall back to shoving the thing into a database.
Plan D: all of the above
In practice, it's unusual to see something can't be handled by A or B.
Perhaps the SRS rewriter could try A first; if it breaks the rules, try
B; if that break the rules, try C as a last resort.
Plan E: shove the original sender into the headers
Pobox will also prepend Old-Return-Path to the headers, showing the
original sender address.
We could shove the full-encapsulated but "overweight" address into
the headers.
X-SRS:
<bounce+foo#aol(_dot_)com-J0*dG7h8yzAwB=bar#pobox(_dot_)com(_at_)bounce(_dot_)pobox(_dot_)com>
Then the rewritten sender address would only need to be
J0*dG7h8yzAwB(_at_)bounce(_dot_)pobox(_dot_)com(_dot_) We would accept the
message,
parse out the X-SRS header, and unwrap based on that.
Of course, this wouldn't work if the reporting MTA didn't include
that header in the message. The only thing you can guarantee is
the return-path.
The ultimate, ideal solution would be for everybody to switch to pgp or
s/mime and then we could do sender authentication based on something
other than client IP address, and the forwarding problem would go away
entirely, but that requires so much upgrading I honestly don't think
it's possible to get there without going through the designated-sender
phase first. People have been pushing for that for years. A designated
sender patch to an MTA is small: you just do DNS. An domain-keys style
patch to an MTA is huge: you have to verify the signature by pulling the
public key out of DNS or some other key server. SPF will work with
domainkeys: "v=spf1 a mx domainkey:dk.%{d} -all" but the challenge is
getting MTAs everywhere to support that mechanism.
Forwarders would have to do SRS even if SPF didn't exist. AOL has
already published its outbound domain list, and antispam software
already scores incoming messages accordingly. Forwarders have been
getting squeezed from both sides for a while. If you don't have many
forwarding aliases, you may not have noticed, but we have.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡