Re: ezmlm and BATV

Sami Farin <[email protected]> Wed, 3 Oct 2007 13:29:57 +0300
Newsgroups gmane.mail.ezmlm
Message-ID <[email protected]>
On Tue, Oct 02, 2007 at 17:14:23 -0600, Bruce Guenter wrote:
...
> > Yes, from what I understand about BATV, that is the desired outcome.
> > Bounces always go to the encoded address; regular deliveries always go
> > to the plain address.
> 
> That wouldn't be too hard to do, especially with the address form in the
> latest draft.  Simply add a common function to advance the sender
> address pointer past the prvs=CODE= and apply it everywhere appropriate.
> I have no good ideas how to handle it if different indistinguishable
> forms are in use.

Instead of attempting to figure them out, you could add a new feature
to ezmlm-idx.

- for users of ABBS and spinoffs like BATV, subscription (to lists
  which require that SENDER is subscribed) goes differently:
  instead of list-subscribe@domain they send email to
  list-subscribekey-xxxxxxxx@domain .
- list-subscribekey is identical to list-subscribe, except for:
  1) when they confirm subscription request, they are given individualized
     list posting email, list-key-yyyyyyyy@domain , and telling which From
     header field they must use, and which xxxxxxxx they used.
     yyyyyyyy is constructed as:
     HMAC("subscribekey", list, xxxxxxxx, From)
     where list is string list@domain ,
     xxxxxxxx is user-specified secret in list-subscribekey-xxxxxxxx,
     From is user's email from From header field in canonical form
     (lower case, no comments etc).
     '\0' is used as a delimeter when calculating HMAC.
     xxxxxxxx can contain only chars [a-z0-9].
     HMAC is calculated using cryptographically secure algorithm.
     HMAC also involves a secret key (ezmlm already creates that key).
     but it could be changed to read data from /dev/*random instead
     (that's what my version does).

     list-key-yyyyyyyy@domain behaves like list@domain, except
     that SENDER is ignored.  list-key-yyyyyyyy@domain should
     be in Bcc header field (ezmlm doesn't see it, naturally), and
     list@domain in Cc or To header field (as usual).
     when ezmlm receives email to list@domain for which it can't find
     SENDER in subscriber list, it consults if From header field
     is found in subscriberkey (or whatever) list -- if yes, it does not
     send email telling email was rejected...  instead, it expects
     mail to arrive for handler of list-key-*.

     subscribers using list-subscribekey -feature are stored in
     different file along with the secret xxxxxxxx specified in
     list-subscribekey-xxxxxxxx.

  2) users of list-subscribekey -feature can post to
     list-key-yyyyyyyy@domain , in which case the following is done:
     - HMAC is checked as specified earlier.
       there is only one valid yyyyyyyy for any one From header field.
     - Bcc header field is nuked just to be sure

  3) unsubscribing requires use of correct xxxxxxxx , or
     forge-unsubscribe-requests can flood the poor user.
     but that can also happen without list-subscribekey -feature,
     in which case usage of secret xxxxxxxx can be omitted from ezmlm
     if it seems too complex.   or a command line switch?
     -1 and -2 are free for use =)

  4) usage of timestamps can be done in list-key-yyyyyyyy@domain ,
     in which case maximum lifetime can be specified for
     list-key-yyyyyyyy: ezmlm gives out email
     list-key-yyyyyyyy-1191406462@domain instead, and compares current
     time against 1191406462.  1191406462 is time(NULL) created in
     step 1).
     If usage of timestamps seems useful, HMAC is specified as
     HMAC("subscribekey", "1", "1191406462", list, xxxxxxxx, From)
     if timestamps are enabled, or
     HMAC("subscribekey", "0", "0", list, xxxxxxxx, From)
     if timestamps are disabled.

--
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHA28lMCYCLUwuV18RArmmAJ9+IH9JFIp3iJjzuuA8AzxztyeHOwCeO4GR
CQVTBgPdemWD8lpPf5mex+Q=
=6Z7x
-----END PGP SIGNATURE-----