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