Re: ezmlm and BATV

Bruce Guenter <[email protected]> writes:

> On Thu, Aug 02, 2007 at 09:27:11AM -0700, John Keith wrote:

>> When this user decides to post a message to the list, ezmlm looks at
>> the envelope sender, [email protected], and rejects
>> the posting because that address does not exist in the subscriber
>> list.
>
> Actually, this simplifies the problem somewhat.  Decoding the BATV
> signed address into a database address would have to happen in quite a
> number of places.  For example, how would such a sender initially
> subscribe or later unsubscribe?

What we do is manage memberships in an organization and from there
subscribe people to mailing lists via ezmlm-sub and ezmlm-unsub.  Users
join the organization using their plain email address, so there's no
subscription issue.  

All the issues come later when these same people use their encoded
address to post messages.  Just a few so far, but they're very vocal
because the 'mu' list config always sends their message to the
moderator.  It's even worse if the list config simply rejects
non-subscribers.

> Also, from reading the draft above, it indicates that the encoded
> address should be [email protected].  Is that what
> you are seeing or the reverse that you posted above?

We are seeing both encoding methods in practice, so it's a bit
confusing.  More so because, as you point out, the drafts have all
expired.  I think I've seen three variants of the encoding thus far.

I'm all for standards, but not shifting sands, so it's difficult to keep
getting dinged for not implementing this one.  Nevertheless, we continue
to hear about it periodically.

> If ezmlm-idx always strips off the leading prvs=CODE= part, is that
> sufficient to communicate with systems utilizing BATV?  That would
> mean that the plain address is stored in the database, and all email
> (except for bounces created automatically by qmail) would be sent to
> the plain address.

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.

Anyway, thanks for your reply Bruce.  I think this type of thing could
be more common in the future.  We're probably hearing it sooner because
we're hosting lists for groups such as the Messaging Anti-Abuse Working
Group, and their members are more likely to be trying new tactics such
as BATV.

I can probably craft something that does the prvs= stripping (accounting
for the encoding variations) for ths specific case.  I guess I wouldn't
really want to see ezmlm get this support until it's firmed up in a
published RFC.

          - John