Mailing List Archive

ANNOUNCE: Mail::SRS v0.21
The releases of Mail::SRS have not been accompanied by fanfare for a few
versions. Version 0.21 merits fanfare since it incorporates the variable
separator feature requested by so many users. qmail users, for example,
may now specify "Separator => '+'" to the constructor, and create "srs0"
and "srs1" users which will receive all SRS emails.

Note that only the initial separator is specified. The rest MUST and will
remain the = sign. However, this does not affect this functionality.

Note that although there was a release of this functionality in version
0.20, it was not an idempotent transformation over multiple stages with
different separators. This has now been fixed. Please upgrade to version
0.21.

Version 0.22 will contain documentation fixes and further tests, but no
further changes in functionality are forseen.

Thanks.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
Re: ANNOUNCE: Mail::SRS v0.21 [ In reply to ]
----- Original Message -----
From: "Shevek" <spf@anarres.org>
To: "SPF Discussion List" <spf-discuss@v2.listbox.com>
Sent: Tuesday, February 17, 2004 12:29 PM
Subject: [spf-discuss] ANNOUNCE: Mail::SRS v0.21

> The releases of Mail::SRS have not been accompanied by fanfare for a few
> versions. Version 0.21 merits fanfare since it incorporates the variable
> separator feature requested by so many users. qmail users, for example,
> may now specify "Separator => '+'" to the constructor,

And sendmail users. :) Again, thanks for accommodating us.

> Note that although there was a release of this functionality in version
> 0.20, it was not an idempotent transformation over multiple stages with
> different separators. This has now been fixed. Please upgrade to version
> 0.21.
>
> Version 0.22 will contain documentation fixes and further tests, but no
> further changes in functionality are forseen.

Can I take this, more or less, as a promise? I am implementing SRS,
system-wide, now; and I really hope we're not going to throw everything
around again.

Thanks,

- Mark

System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
Re: ANNOUNCE: Mail::SRS v0.21 [ In reply to ]
On Tue, 17 Feb 2004, Mark wrote:

> > The releases of Mail::SRS have not been accompanied by fanfare for a few
> > versions. Version 0.21 merits fanfare since it incorporates the variable
> > separator feature requested by so many users. qmail users, for example,
> > may now specify "Separator => '+'" to the constructor,
>
> And sendmail users. :) Again, thanks for accommodating us.

Thankyou. This seems to be a very popular change.

> > Note that although there was a release of this functionality in version
> > 0.20, it was not an idempotent transformation over multiple stages with
> > different separators. This has now been fixed. Please upgrade to version
> > 0.21.
> >
> > Version 0.22 will contain documentation fixes and further tests, but no
> > further changes in functionality are forseen.
>
> Can I take this, more or less, as a promise? I am implementing SRS,
> system-wide, now; and I really hope we're not going to throw everything
> around again.

We most sincerely hope and intend so. The variable-separator feature
introduced one change in the implementation in order to preserve this
variable separator. That is the only protocol change since the SRS1 format
was introduced.

I hasten to point out that since things like timestamp and hash are only
locally interpreted on the generating system, parties are free to define
these as they wish, and that any changes to the default implementations of
these would not impact existing systems. The only responsibility of the
SRS developers with regard to locally interpreted fields is to propose a
standard field layout such that multiple forwarders may interact
correctly, and a sane and sensible default encoding mechanism without any
fundamental weaknesses. This means that a) we're allowed to change the
hash algorithm in future releases, and b) it doesn't affect you if we do.

Thanks.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h