Mail::Milter::Wrapper::DecodeSRS (3pm)

    use Mail::Milter::Wrapper::DecodeSRS;

my $milter = ...; my $wrapper = new Mail::Milter::Wrapper::DecodeSRS($milter);

my $wrapper2 = &DecodeSRS($milter); # convenience

Mail::Milter::Wrapper::DecodeSRS is a convenience milter wrapper which decodes \s-1MAIL\s0 \s-1FROM:\s0 return paths which have been encoded by the Sender Rewrite Scheme, \s-1SRS\s0. (More information: http://www.libsrs2.org/) This wrapper internally understands both the \s-1SRS0\s0 and \s-1SRS1\s0 encoding schemes documented by the Mail::SRS author.

The decoded address is made available to the contained milter via the \*(C`envfrom\*(C' callback, in the same way that a raw address would.

\s-1NOTE:\s0 If the address is not \s-1SRS\s0 encoded, the contained milter is \s-1NOT\s0 called for the duration of the message; instead, \s-1SMFIS_ACCEPT\s0 is returned. This is because the milter writer is expected to use this wrapper in a chain that also includes the contained milter without wrapping, in order to prevent a malicious sender from using \s-1SRS\s0 to bypass access checks.

For instance, the following is a proper usage of this wrapper in a chain:

my $envfrommilter = ...;

my $combinedmilter = new Mail::Milter::Chain( new Mail::Milter::Wrapper::UnwrapSRS($envfrommilter), $envfrommilter );

This behavior can also be used if, e.g., the \s-1MTA\s0 already does one form of \s-1MAIL\s0 \s-1FROM:\s0 check, and the contained milter repeats that same database check against \s-1SRS\s0 rewritten addresses. (A good example would be a milter emulating Sendmail's access_db map.)

Todd Vierling, <[email protected]> <[email protected]>

Mail::Milter::Wrapper