.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{
.    if \nF \{
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "Mail::SRS 3"
.TH Mail::SRS 3 "2004-10-19" "perl v5.16.3" "User Contributed Perl Documentation"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
Mail::SRS \- Interface to Sender Rewriting Scheme
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
.Vb 9
\&        use Mail::SRS;
\&        my $srs = new Mail::SRS(
\&                Secret     => [ .... ],    # scalar or array
\&                MaxAge     => 49,          # days
\&                HashLength => 4,           # base64 characters: 4 x 6bits
\&                HashMin    => 4,           # base64 characters
\&                        );
\&        my $srsaddress = $srs\->forward($sender, $alias);
\&        my $sender = $srs\->reverse($srsaddress);
.Ve
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The Sender Rewriting Scheme preserves .forward functionality in an
SPF-compliant world.
.PP
\&\s-1SPF\s0 requires the \s-1SMTP\s0 client \s-1IP\s0 to match the envelope sender
(return-path). When a message is forwarded through an intermediate
server, that intermediate server may need to rewrite the return-path
to remain \s-1SPF\s0 compliant. If the message bounces, that intermediate
server needs to validate the bounce and forward the bounce to the
original sender.
.PP
\&\s-1SRS\s0 provides a convention for return-path rewriting which allows
multiple forwarding servers to compact the return-path. \s-1SRS\s0 also
provides an authentication mechanism to ensure that purported bounces
are not arbitrarily forwarded.
.PP
\&\s-1SRS\s0 is documented at http://spf.pobox.com/srs.html and many points
about the scheme are discussed at http://www.anarres.org/projects/srs/
.PP
For a better understanding of this code and how it functions, please
read this document and run the interactive walkthrough in eg/simple.pl
in this distribution. To run this from the build directory, type
\&\*(L"make teach\*(R".
.SH "METHODS"
.IX Header "METHODS"
.ie n .SS "$srs = new Mail::SRS(...)"
.el .SS "\f(CW$srs\fP = new Mail::SRS(...)"
.IX Subsection "$srs = new Mail::SRS(...)"
Construct a new Mail::SRS object and return it. Available parameters
are:
.ie n .IP "Secret => $string" 4
.el .IP "Secret => \f(CW$string\fR" 4
.IX Item "Secret => $string"
A key for the cryptographic algorithms. This may be an array or a single
string. A string is promoted into an array of one element.
.IP "MaxAge" 4
.IX Item "MaxAge"
The maximum number of days for which a timestamp is considered
valid. After this time, the timestamp is invalid.
.ie n .IP "HashLength => $integer" 4
.el .IP "HashLength => \f(CW$integer\fR" 4
.IX Item "HashLength => $integer"
The number of bytes of base64 encoded data to use for the cryptographic
hash. More is better, but makes for longer addresses which might
exceed the 64 character length suggested by \s-1RFC2821.\s0 This defaults to
4, which gives 4 x 6 = 24 bits of cryptographic information, which
means that a spammer will have to make 2^24 attempts to guarantee
forging an \s-1SRS\s0 address.
.ie n .IP "HashMin => $integer" 4
.el .IP "HashMin => \f(CW$integer\fR" 4
.IX Item "HashMin => $integer"
The shortest hash which we will allow to pass authentication. Since we
allow any valid prefix of the full \s-1SHA1 HMAC\s0 to pass authentication,
a spammer might just suggest a hash of length 0. We require at least
HashMin characters, which must all be correct. Naturally, this must
be no greater than HashLength and will default to HashLength unless
otherwise specified.
.ie n .IP "Separator => $character" 4
.el .IP "Separator => \f(CW$character\fR" 4
.IX Item "Separator => $character"
Specify the initial separator to use immediately after the \s-1SRS\s0 tag. \s-1SRS\s0
uses the = separator throughout \s-1EXCEPT\s0 for the initial separator,
which may be any of + \- or =.
.Sp
Some MTAs already have a feature by which text after a + or \- is
ignored for the purpose of identifying a local recipient. If the
initial separator is set to + or \-, then an administrator may process
all \s-1SRS\s0 mails by creating users \s-1SRS0\s0 and \s-1SRS1,\s0 and using Mail::SRS
in the default delivery rule for these users.
.Sp
Some notes on the use and preservation of these separators are found
in the perldoc for Mail::SRS::Guarded.
.ie n .IP "AlwaysRewrite => $boolean" 4
.el .IP "AlwaysRewrite => \f(CW$boolean\fR" 4
.IX Item "AlwaysRewrite => $boolean"
\&\s-1SRS\s0 rewriting is not performed by default if the alias host matches
the sender host, since it would be unnecessary to do so, and it
interacts badly with ezmlm if we do. Set this to true if you want
always to rewrite when requested to do so.
.ie n .IP "IgnoreTimestamp => $boolean" 4
.el .IP "IgnoreTimestamp => \f(CW$boolean\fR" 4
.IX Item "IgnoreTimestamp => $boolean"
Consider all timestamps to be valid. Defaults to false. It is \s-1STRONGLY\s0
recommended that this remain false. This parameter is provided so that
timestamps may be ignored temporarily after a change in the timestamp
format or encoding, until all timestamps in the old encoding would
have become invalid. Note that timestamps still form a part of the
cryptographic data when this is enabled.
.IP "AllowUnsafeSrs" 4
.IX Item "AllowUnsafeSrs"
This is a backwards compatibility option for an older version of the
protocol where \s-1SRS1\s0 was not hash-protected. The 'reverse' method
will detect such addresses, and handle them properly. Deployments
upgrading from version <=0.27 to any version >=0.28 should enable
this for MaxAge+1 days.
.Sp
When this option is enabled, all new addresses will be generated with
cryptographic protection.
.PP
Some subclasses require other parameters. See their documentation for
details.
.ie n .SS "$srsaddress = $srs\->forward($sender, $alias)"
.el .SS "\f(CW$srsaddress\fP = \f(CW$srs\fP\->forward($sender, \f(CW$alias\fP)"
.IX Subsection "$srsaddress = $srs->forward($sender, $alias)"
Map a sender address into a new sender and a cryptographic cookie.
Returns an \s-1SRS\s0 address to use as the new sender.
.PP
There are alternative subclasses, some of which will return \s-1SRS\s0
compliant addresses, some will simply return non-SRS but valid \s-1RFC821\s0
addresses. See the interactive walkthrough for more information on this
(\*(L"make teach\*(R").
.ie n .SS "$sender = $srs\->reverse($srsaddress)"
.el .SS "\f(CW$sender\fP = \f(CW$srs\fP\->reverse($srsaddress)"
.IX Subsection "$sender = $srs->reverse($srsaddress)"
Reverse the mapping to get back the original address. Validates all
cryptographic and timestamp information. Returns the original sender
address. This method will die if the address cannot be reversed.
.ie n .SS "$srs\->compile($sendhost, $senduser)"
.el .SS "\f(CW$srs\fP\->compile($sendhost, \f(CW$senduser\fP)"
.IX Subsection "$srs->compile($sendhost, $senduser)"
This method, designed to be overridden by subclasses, takes as
parameters the original host and user and must compile a new username
for the \s-1SRS\s0 transformed address. It is expected that this new username
will be joined on \f(CW$SRSSEP\fR, and will contain a hash generated from
\&\f(CW$self\fR\->hash_create(...), and possibly a timestamp generated by
\&\f(CW$self\fR\->\fItimestamp_create()\fR.
.ie n .SS "$srs\->parse($srsuser)"
.el .SS "\f(CW$srs\fP\->parse($srsuser)"
.IX Subsection "$srs->parse($srsuser)"
This method, designed to be overridden by subclasses, takes an
SRS-transformed username as an argument, and must reverse the
transformation produced by \fIcompile()\fR. It is required to verify any
hash and timestamp in the parsed data, using \f(CW$self\fR\->hash_verify($hash,
\&...) and \f(CW$self\fR\->timestamp_check($timestamp).
.ie n .SS "$srs\->timestamp_create([$time])"
.el .SS "\f(CW$srs\fP\->timestamp_create([$time])"
.IX Subsection "$srs->timestamp_create([$time])"
Return a two character timestamp representing 'today', or \f(CW$time\fR if
given. \f(CW$time\fR is a Unix timestamp (seconds since the aeon).
.PP
This Perl function has been designed to be agnostic as to base,
and in practice, base32 is used since it can be reversed even if a
remote \s-1MTA\s0 smashes case (in violation of \s-1RFC2821\s0 section 2.4). The
agnosticism means that the Perl uses division instead of rightshift,
but in Perl that doesn't matter. C implementors should implement this
operation as a right shift by 5.
.ie n .SS "$srs\->timestamp_check($timestamp)"
.el .SS "\f(CW$srs\fP\->timestamp_check($timestamp)"
.IX Subsection "$srs->timestamp_check($timestamp)"
Return 1 if a timestamp is valid, undef otherwise. There are 4096
possible timestamps, used in a cycle. At any time, \f(CW$srs\fR\->{MaxAge}
timestamps in this cycle are valid, the last one being today. A
timestamp from the future is not valid, neither is a timestamp from
too far into the past. Of course if you go far enough into the future,
the cycle wraps around, and there are valid timestamps again, but the
likelihood of a random timestamp being valid is 4096/$srs\->{MaxAge},
which is usually quite small: 1 in 132 by default.
.ie n .SS "$srs\->time_check($time)"
.el .SS "\f(CW$srs\fP\->time_check($time)"
.IX Subsection "$srs->time_check($time)"
Similar to \f(CW$srs\fR\->timestamp_check($timestamp), but takes a Unix time, and
checks that an alias created at that Unix time is still valid. This is
designed for use by subclasses with storage backends.
.ie n .SS "$srs\->hash_create(@data)"
.el .SS "\f(CW$srs\fP\->hash_create(@data)"
.IX Subsection "$srs->hash_create(@data)"
Returns a cryptographic hash of all data in \f(CW@data\fR. Any piece of data
encoded into an address which must remain inviolate should be hashed,
so that when the address is reversed, we can check that this data has
not been tampered with. You must provide at least one piece of data
to this method (otherwise this system is both cryptographically weak
and there may be collision problems with sender addresses).
.ie n .SS "$srs\->hash_verify($hash, @data)"
.el .SS "\f(CW$srs\fP\->hash_verify($hash, \f(CW@data\fP)"
.IX Subsection "$srs->hash_verify($hash, @data)"
Verify that \f(CW@data\fR has not been tampered with, given the cryptographic
hash previously output by \f(CW$srs\fR\->\fIhash_create()\fR; Returns 1 or undef.
All known secrets are tried in order to see if the hash was created
with an old secret.
.ie n .SS "$srs\->set_secret($new, @old)"
.el .SS "\f(CW$srs\fP\->set_secret($new, \f(CW@old\fP)"
.IX Subsection "$srs->set_secret($new, @old)"
Add a new secret to the rewriter. When an address is returned, all
secrets are tried to see if the hash can be validated. Don't use \*(L"foo\*(R",
\&\*(L"secret\*(R", \*(L"password\*(R", \*(L"10downing\*(R", \*(L"god\*(R" or \*(L"wednesday\*(R" as your secret.
.ie n .SS "$srs\->\fIget_secret()\fP"
.el .SS "\f(CW$srs\fP\->\fIget_secret()\fP"
.IX Subsection "$srs->get_secret()"
Return the list of secrets. These are secret. Don't publish them.
.ie n .SS "$srs\->\fIseparator()\fP"
.el .SS "\f(CW$srs\fP\->\fIseparator()\fP"
.IX Subsection "$srs->separator()"
Return the initial separator, which follows the \s-1SRS\s0 tag. This is only
used as the initial separator, for the convenience of administrators
who wish to make srs0 and srs1 users on their mail servers and require
to use + or \- as the user delimiter. All other separators in the \s-1SRS\s0
address must be \f(CW\*(C`=\*(C'\fR.
.SH "EXPORTS"
.IX Header "EXPORTS"
Given :all, this module exports the following variables.
.ie n .IP "$SRSSEP" 4
.el .IP "\f(CW$SRSSEP\fR" 4
.IX Item "$SRSSEP"
The \s-1SRS\s0 separator. The choice of \f(CW\*(C`=\*(C'\fR as internal separator was fairly
arbitrary. It cannot be any of the following:
.RS 4
.IP "/ +" 4
Used in Base64.
.IP "\-" 4
Used in domains.
.IP "! %" 4
Used in bang paths and source routing.
.IP ":" 4
Cannot be used in a Windows \s-1NT\s0 or Apple filename.
.IP "; | *" 4
Shell or regular expression metacharacters are probably to be avoided.
.RE
.RS 4
.RE
.ie n .IP "$SRS0TAG" 4
.el .IP "\f(CW$SRS0TAG\fR" 4
.IX Item "$SRS0TAG"
The \s-1SRS0\s0 tag.
.ie n .IP "$SRS1TAG" 4
.el .IP "\f(CW$SRS1TAG\fR" 4
.IX Item "$SRS1TAG"
The \s-1SRS1\s0 tag.
.ie n .IP "$SRSTAG" 4
.el .IP "\f(CW$SRSTAG\fR" 4
.IX Item "$SRSTAG"
Deprecated, equal to \f(CW$SRS0TAG\fR.
.ie n .IP "$SRSWRAP" 4
.el .IP "\f(CW$SRSWRAP\fR" 4
.IX Item "$SRSWRAP"
Deprecated, equal to \f(CW$SRS1TAG\fR.
.ie n .IP "$SRSHASHLENGTH" 4
.el .IP "\f(CW$SRSHASHLENGTH\fR" 4
.IX Item "$SRSHASHLENGTH"
The default hash length for the \s-1SRS HMAC.\s0
.ie n .IP "$SRSMAXAGE" 4
.el .IP "\f(CW$SRSMAXAGE\fR" 4
.IX Item "$SRSMAXAGE"
The default expiry time for timestamps.
.SH "EXAMPLES OF USAGE"
.IX Header "EXAMPLES OF USAGE"
For people wanting boilerplate and those less familiar with using
Perl modules in larger applications.
.SS "Forward Rewriting"
.IX Subsection "Forward Rewriting"
.Vb 10
\&        my $srs = new Mail::SRS(...);
\&        my $address = ...
\&        my $domain = ...
\&        my $srsaddress = eval { $srs\->forward($srsaddress, $domain); };
\&        if ($@) {
\&                # The rewrite failed
\&        }
\&        else {
\&                # The rewrite succeeded
\&        }
.Ve
.SS "Reverse Rewriting"
.IX Subsection "Reverse Rewriting"
.Vb 9
\&        my $srs = new Mail::SRS(...);
\&        my $srsaddress = ...
\&        my $address = eval { $srs\->reverse($srsaddress); };
\&        if ($@) {
\&                # The rewrite failed
\&        }
\&        else {
\&                # The rewrite succeeded
\&        }
.Ve
.SH "NOTES ON SRS"
.IX Header "NOTES ON SRS"
.SS "Case Sensitivity"
.IX Subsection "Case Sensitivity"
\&\s-1RFC2821\s0 states in section 2.4: \*(L"The local-part of a mailbox \s-1MUST BE\s0
treated as case sensitive. Therefore, \s-1SMTP\s0 implementations \s-1MUST\s0 take
care to preserve the case of mailbox local-parts. [...]  In particular,
for some hosts the user \*(R"smith\*(L" is different from the user \*(R"Smith\*(L".
However, exploiting the case sensitivity of mailbox local-parts
impedes interoperability and is discouraged.\*(R"
.PP
\&\s-1SRS\s0 does not rely on case sensitivity in the local part. It uses
base64 for encoding the hash, but allows a case insensitive match,
making this approximately equivalent to base36 at worst. It will
issue a warning if it detects that a remote \s-1MTA\s0 has smashed case. The
timestamp is encoded in base32.
.SS "The 64 Billion Character Question"
.IX Subsection "The 64 Billion Character Question"
\&\s-1RFC2821\s0 section 4.5.3.1: Size limits and minimums:
.PP
.Vb 10
\&        There are several objects that have required minimum/maximum
\&        sizes.  Every implementation MUST be able to receive objects
\&        of at least these sizes. Objects larger than these sizes
\&        SHOULD be avoided when possible. However, some Internet
\&        mail constructs such as encoded X.400 addresses [16] will
\&        often require larger objects: clients MAY attempt to transmit
\&        these, but MUST be prepared for a server to reject them if
\&        they cannot be handled by it. To the maximum extent possible,
\&        implementation techniques which impose no limits on the length
\&        of these objects should be used.
\&
\&        local\-part
\&                The maximum total length of a user name or other
\&                local\-part is 64 characters.
.Ve
.PP
Clearly, by including 2 domain names and a local-part in the rewritten
address, there is no way in which \s-1SRS\s0 can guarantee to stay under
this limit. However, very few systems are known to actively enforce
this limit, and those which become known to the developers will be
listed here.
.IP "Cisco: \s-1PIX\s0 MailGuard (firewall gimmick)" 4
.IX Item "Cisco: PIX MailGuard (firewall gimmick)"
.PD 0
.IP "WebShield [something] (firewall gimmick)" 4
.IX Item "WebShield [something] (firewall gimmick)"
.PD
.SS "Invalid \s-1SRS\s0 Addresses"
.IX Subsection "Invalid SRS Addresses"
\&\s-1DO NOT MALFORMAT ADDRESSES.\s0 This is designed to be an interoperable
format. Certain things are allowed, such as changing the semantics
of the hash or the timestamp. However, both of these fields must
be present and separated by the \s-1SRS\s0 separator character \f(CW\*(C`=\*(C'\fR. The
purpose of this section is to illustrate that if a malicious party
were to malformat an address, he would gain nothing by doing so,
nor would the network suffer.
.PP
The \s-1SRS\s0 protocol is predicated on the fact that the first forwarder
provides a cryptographic wrapper on the forward chain for sending
mail to the original sender. So what happens if an \s-1SRS\s0 address is
invalid, or faked by a spammer?
.PP
The minimum parsing of existing \s-1SRS\s0 addresses is done at each hop. If
an \s-1SRS0\s0 address is not valid or badly formatted, it will not affect
the operation of the system: the mail will go out along the forwarder
chain, and return to the invalid or badly formatted address.
.PP
If the spammer is not pretending to be the first hop, then he
must somehow construct an \s-1SRS0\s0 address to embed within his \s-1SRS1\s0
address. The cryptographic checks on this \s-1SRS0\s0 address will fail at
the first forwarder and the mail will be dropped.
.PP
If the spammer is pretending to be the first hop, then \s-1SPF\s0 should
require that any bounces coming back return to his mail server,
thus he wins nothing.
.SS "Cryptographic Systems"
.IX Subsection "Cryptographic Systems"
The hash in the address is designed to prevent the forging of reverse
addresses by a spammer, who might then use the \s-1SRS\s0 host as a forwarder.
It may only be constructed or validated by a party who knows the
secret key.
.PP
The cryptographic system in the default implementation is not mandated.
Since nobody else ever needs to interpret the hash, it is reasonable
to put any binary data into this field (subject to the possible
constraint of case insensitive encoding).
.PP
The \s-1SRS\s0 maintainers have attempted to provide a good system. It
satisfies a simple set of basic requirements: to provide unforgeability
of \s-1SRS\s0 addresses given that every \s-1MTA\s0 for a domain shares a secret key.
We prefer \s-1SHA1\s0 over \s-1MD5\s0 for political, rather than practical reasons.
(Anyone disputing this statement must include an example of a practical
weakness in their mail. We would love to see it.)
.PP
If you find a weakness in our system, or you think you know of a
better system, please tell us. If your requirements are different,
you may override \fIhash_create()\fR and \fIhash_verify()\fR to implement a
different system without adversely impacting the network, as long as
your addresses still behave as \s-1SRS\s0 addresses.
.SS "Extending Mail::SRS"
.IX Subsection "Extending Mail::SRS"
Write a subclass. You will probably want to override \fIcompile()\fR and
\&\fIparse()\fR. If you are more familiar with the internals of \s-1SRS,\s0 you might
want to override \fIhash_create()\fR, \fIhash_verify()\fR, \fItimestamp_create()\fR
or \fItimestamp_check()\fR.
.SH "CHANGELOG"
.IX Header "CHANGELOG"
.SS "\s-1MINOR CHANGES\s0 since v0.29"
.IX Subsection "MINOR CHANGES since v0.29"
.IP "timestamp_check now explicitly smashes case when verifying. This means that the base used must be base32, \s-1NOT\s0 base64." 4
.IX Item "timestamp_check now explicitly smashes case when verifying. This means that the base used must be base32, NOT base64."
.PD 0
.IP "hash_create and hash_verify now explicitly smash case when creating and verifying hashes. This does not have a significant cryptographic impact." 4
.IX Item "hash_create and hash_verify now explicitly smash case when creating and verifying hashes. This does not have a significant cryptographic impact."
.PD
.SS "\s-1MAJOR CHANGES\s0 since v0.27"
.IX Subsection "MAJOR CHANGES since v0.27"
.IP "The \s-1SRS1\s0 address format has changed to include cryptographic information. Existing deployments should consider setting AllowUnsafeSrs for MaxAge+1 days." 4
.IX Item "The SRS1 address format has changed to include cryptographic information. Existing deployments should consider setting AllowUnsafeSrs for MaxAge+1 days."
.SS "\s-1MINOR CHANGES\s0 since v0.26"
.IX Subsection "MINOR CHANGES since v0.26"
.PD 0
.IP "\fIparse()\fR and \fIcompile()\fR are explicitly specified to \fIdie()\fR on error." 4
.IX Item "parse() and compile() are explicitly specified to die() on error."
.PD
.SS "\s-1MINOR CHANGES\s0 since v0.23"
.IX Subsection "MINOR CHANGES since v0.23"
.IP "Update \s-1BASE32\s0 according to \s-1RFC3548.\s0" 4
.IX Item "Update BASE32 according to RFC3548."
.SS "\s-1MINOR CHANGES\s0 since v0.21"
.IX Subsection "MINOR CHANGES since v0.21"
.PD 0
.IP "Dates are now encoded in base32." 4
.IX Item "Dates are now encoded in base32."
.IP "Case insensitive \s-1MAC\s0 validation is now allowed, but will issue a warning." 4
.IX Item "Case insensitive MAC validation is now allowed, but will issue a warning."
.PD
.SS "\s-1MINOR CHANGES\s0 since v0.18"
.IX Subsection "MINOR CHANGES since v0.18"
.ie n .IP "$SRSTAG and $SRSWRAP are deprecated." 4
.el .IP "\f(CW$SRSTAG\fR and \f(CW$SRSWRAP\fR are deprecated." 4
.IX Item "$SRSTAG and $SRSWRAP are deprecated."
.PD 0
.IP "Mail::SRS::Reversable is now Mail::SRS::Reversible" 4
.IX Item "Mail::SRS::Reversable is now Mail::SRS::Reversible"
.PD
This should not be a problem since people should not be using it!
.PP
You must use \f(CW$SRS0RE\fR and \f(CW$SRS1RE\fR to detect \s-1SRS\s0 addresses.
.SS "\s-1MAJOR CHANGES\s0 since v0.15"
.IX Subsection "MAJOR CHANGES since v0.15"
.ie n .IP "The separator character is now ""=""." 4
.el .IP "The separator character is now \f(CW=\fR." 4
.IX Item "The separator character is now =."
.PD 0
.IP "The cryptographic scheme is now \s-1HMAC\s0 with \s-1SHA1.\s0" 4
.IX Item "The cryptographic scheme is now HMAC with SHA1."
.IP "Only a prefix of the \s-1MAC\s0 is used." 4
.IX Item "Only a prefix of the MAC is used."
.PD
.PP
This \s-1API\s0 is still a release candidate and should remain relatively
stable.
.SH "BUGS"
.IX Header "BUGS"
Email address parsing for quoted addresses is not yet done properly.
.PP
Case insensitive \s-1MAC\s0 validation should become an option.
.SH "TODO"
.IX Header "TODO"
Write a testsuite for testing user-defined \s-1SRS\s0 implementations.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
Mail::SRS::Guarded, Mail::SRS::DB, Mail::SRS::Reversable,
\&\*(L"make teach\*(R", eg/*, http://www.anarres.org/projects/srs/
.SH "AUTHOR"
.IX Header "AUTHOR"
.Vb 4
\&        Shevek
\&        CPAN ID: SHEVEK
\&        cpan@anarres.org
\&        http://www.anarres.org/projects/
.Ve
.SH "COPYRIGHT"
.IX Header "COPYRIGHT"
Copyright (c) 2004 Shevek. All rights reserved.
.PP
This program is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.