[Mailman-Developers] Quandry 2: Alternate hosts and sendmail

[Ken Manheimer]

I'm hitting a bit of a quandry in determining the _correct_ setting
for the sender of the subscription confirmation-request message (the
thing sent when web_subscribe_requires_confirmation is "Requestor
confirms via email"), and am wondering if anyone has a simple, clear
answer.

The problem is in some conflicting constraints in the
confirmation-request return address, which can be resolved in most
cases by judicious use of the sender and reply-to message fields, but
which apparently cannot be resolved simply in a way that satisfies all
MUAs.

Here are the constraints:

 1 Regular replies to the confirmation request should be directed to
   the list's "-request" address (where it will be processed by the
   mailcmd script).

 2 A slightly more obscure constraint is that errors should be
   directed to the -admin address (or perhaps something else), *not*
   to the "-request" addr.

   And, unfortunately, setting the "errors-to" header to the -admin
   addr is not sufficient - in certain cases, eg when the remote
   address specified by the subscriber can't even be resolved in DNS,
   the sender receives the error notice.  I think, but am not sure,
   that there are cases where the message makes it to the remote site
   but errors still get returned to the sender, not errors-to, addr.

It is the last part that dictates what we're currently doing:

  Reply-to:	-request addr
  Sender:	-admin addr
  Errors-to:	-admin addr

This works fine in most cases - users hit "reply" in the MUA, and get
the right response address.  Bounced messages go to the -admin, who
can diagnose the situation and/or ignore it.

Note that i said "most cases" - i, as list administrator, have gotten
a few errant replies from users.  On investigation, it turns out that
a *few* MUAs, eg /bin/mail on some platform(s) or other, do not
respect the reply-to header.  Dammit.

So i guess my question is, is it worth trying a different approach
that will allow both the reply-to *and* the sender to be the -request
addr, just to accomodate the few mailers that don't respect reply-to?

That would probably mean increasing the complexity of the mailcmd
script significantly, to detect requests that are actually bounces of
the confirmation-requests.

I'm just starting to count how often this happens, but it seems like
it could be a real problem for lists with lots of subscriptions...

Is my explanation of the situation clear?  Any strong ideas,
suggestions?

Ken