[Top] [All Lists]

Re: SRS requirements

2004-01-14 11:34:12
| 1) patch to sendmail so /etc/aliases will work transparently
| 2) SRS in .procmail (will probably involve a program |srsforward which calls 
| 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

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

 -> recipient

    The special bounce.pobox.com domain handles SRS bounces exclusively.

Plan B: wildcard DNS

    But what if we do this instead?

 -> recipient

    That keeps the local-part under 64, but may run afoul of total length

    That would require that the special bounce domain have DNS

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.


    Then the rewritten sender address would only need to be
    J0*dG7h8yzAwB(_at_)bounce(_dot_)pobox(_dot_)com(_dot_)  We would accept the 
    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 
please go to 

<Prev in Thread] Current Thread [Next in Thread>