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

Mark <[email protected]> Sun, 21 Nov 2004 08:06:37 GMT
Newsgroups gmane.mail.spam.srs.general
Organization Asarian-host
Message-ID <[email protected]>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Chris Drake
> Sent: zondag 21 november 2004 6:21
> To: Mark
> Subject: Re[4]: [srs-discuss] 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+

SRS addresses can be case-insensitive now, too. The answer (from
SRS.pm) is:

$SRS0TAG = "SRS0";
$SRS1TAG = "SRS1";
$SRS0RE = qr/^$SRS0TAG([-+=])/io;
$SRS1RE = qr/^$SRS1TAG([-+=])/io;

In short, ^SRS[01][-+=]

>  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=".

You can always make a callback, to be absolutely sure it is a valid SRS
address; I mean, a callback is like a remote "reverse" call (which only
returns a boolean: true or false).

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

'-' is most certainly possible as initial separator!

> 8. Mark needs to fix his regexp and send updates to whoever's using
>    it?  [+-=] means the range   +,-./0123456789:;<=

I seem to have copied this old typo again. :( Sigh.

>         [\=\+] is probably the correct one to use?

No. [-+=], however, is.

> I have no idea what set \S+ is going to match, nor whether
> MTAs allow or prevent UTF8 in addresses,

UTF8 in an email address?? I do not find that in RFC 2822. :)

> 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"

You could have an address like this:

Input:  "jan klaasen"@isp.nl
Output: SRS0=9Szq9kxH=OH=isp.nl="jan klaasen"@asarian-host.net

But also one like this:

Input:  [email protected]
Output: SRS0+tP/[email protected]

Where you have a separator character ("+") in the local-part. So,
"anything besides separators" does not exactly work either.

The rexeg can be tidied up, of course, to use backtracking (\1) on the
SRS1 separator, and to allow for pretty much everything in the local-part:

sub unwound_srs {
 (my $addr = (shift)) =~ s/[<>]//g;
  if ($addr =~ /^SRS0[-+=]\S+=\S{2}=(\S+)=(.+)\@\S+$/i) {
    return ("$2\@$1");
  } elsif ($addr =~ /^SRS1([-+=])\S+=\S+=\1\S+=\S{2}=(\S+)=(.+)\@\S+$/i) {
    return ("$3\@$2");
  } else {
    return undef;
  }
}

Mind you, a lot is possible in the local-part; even '@@' is valid,
if quoted or escaped.

> Also be aware that hacking off the "<>" characters may
> destroy UTF8,

If UTF8 were allowed, yes. :)

> 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?

The Milter interface parses those 'extra' parts as additional parameters
to the envfrom_callback, not as one string. Though in the "reverse" call
of SRS.pm, where I used this, this is not pertinent, of course.

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