Re[4]: Help - How to unwind an SRS address?

Hi All,

So correct me if I'm wrong:

1. It's an SRS-re-written address IFF it starts with (case sensitive)
   SRS0=
   SRS1=
   SRS0+
   SRS1+
   and because of database methods, no amount of '=' or '-' or '+' can
   be used after the initial [+=] to further differentiate between an
   SRS rewritten address and someone who's email happens to start with
   "SRS0=".

2. '-' is not possible as the initial separator.

3. The SRS1 separator after "first-forwarder" is one of:-
   ==
   =+

4. '=-' is also not possible (my guess, as I can't see how or why a
   hyphen would have made it before the HHH part, and I'm guessing
   it's the '?HHH' bit that's preserved after the "first-forwarder"'s
   '=' separator ?

5. All other separators are '='

6. HHH and TT etc components MUST not be missing

7. If it's a database-rewritten SRS address, I should try and find the
   sender by considering (in order, reading downwards from the top of
   the headers).
   A: Return-Path: headers - if found - is the real sender
   B: Sender: header (only if no Return-Path: exists)
   C: From: header (as a last resort)

8. Mark needs to fix his regexp and send updates to whoever's using
   it?  [+-=] means the range   +,-./0123456789:;<=
        [\=\+] is probably the correct one to use?
        '==' can't handle SRS1's '=+' possibility?
        I have no idea what set \S+ is going to match, nor whether
          MTAs allow or prevent UTF8 in addresses, and if so, whether
          they allow whatever UTF8 strings are considered spaces [^\S]
          so matching "anything besides separators" is safer than
          matching "anything that's not a space"
        Also be aware that hacking off the "<>" characters may
        destroy UTF8, and depending on where the email address came
        from, your string buffer might be:-
        <[email protected]>
        or maybe
        <[email protected]> SIZE=500
        (the latter being what ESMTP might have sent in the MAIL FROM:
        stage) so take care?

Kind Regards,
Chris Drake


Sunday, November 21, 2004, 2:02:01 PM, you wrote:

M> Mark wrote:

>> > I have never had the need to determine the pre-rewritten sender in
>> > a foreign SRS address, yet.

M> Seth Goodman wrote:

>> I don't recall whether or not the SRS spec mentioned this, but the
>> destination gateway MTA or its MDA should unwrap an SRS address before
>> writing the Return-Path: header.

M> The destination gateway MTA can only perform a pseudo-unwrap, of
M> course (and then only for non-database SRS0 addresses). The database
M> SRS0 addresses, btw, allow for a near zero-tolerance playback defense.
M> I am not sure exactly how thread-safe MLDBM (DB_File) calls really
M> are; or how well and easily you can lock access to the database (for
M> multiple applications, such as Milter and LDA trying to access
M> BerkeleyDB at the same time). Maybe I will write a MySQL interface for
M> it. :)

>> The reason for not exposing an SRS address to the end user is to
>> reduces the possibility of an SRS signed address being harvested and
>> used to create forged bounces to the SRS0 rewriting forwarder, who
>> will accept the forgery and deliver it to the original sender.  The
>> original sender can only be spammed this way until the SRS0 signature
>> expires, so it is not a major problem.

M> Yes. The problem is, of course, programs like SA, who like to have a
M> go at SPF too. With no SRS 'original' Return-Path to be found any
M> more, they are stuck (I'm sure something can be done with HELO,
M> in those cases; but that offers no real substitute for per-virtual
M> domain SPF policies).

>> > Any foreign SRS entity can be checked "as is" (for callbacks and
>> > such, if you had those in mind). In fact, 'unrolling' them first, and
>> > then do remote checks on them, may even be worse.

>> If the original sender rewrites all return-paths as SRS0 addresses to
>> accomplish SES, a callback to the unsigned address should fail.

M> Callbacks to such 'unrolled' addresses would fail here.

>> Callback requests to the signed address, OTOH, should succeed.

M> Indeed. That is why the OP, if he had callbacks in mind, best do them
M> on the SRS addresses "as is". It is the responsibility of the sending MTA
M> to deal with them on return.

M> - Mark 
 
M>         System Administrator Asarian-host.org
 
M> ---
M> "If you were supposed to understand it,
M> we wouldn't call it code." - FedEx

M> -------
M> To unsubscribe, change your address, or temporarily deactivate your subscription,
M> please go to
M> http://v2.listbox.com/member/[email protected]