> A request comes into a smartlist-managed request alias, where the
> "From:" headers are unqualified, but the address on the "subscribe
> ADDRESS" command *is* fully-qualified.
A reasonable list manager should be able to handle it. You add the
fully-qualified address in the subscribe command, and send a reply to
both the requester (from the envelope return address) and the person
being subscribed. The reply to the requester might bounce, but the
person will still get the acknowledgement.
Of course, this won't work if you insist that people only subscribe by
sending mail from the address that they're subscribing to.
> Our mailer, on the assumption that "plain", unqualified names can only
> be local, qualifies the names with our default domain. Thus, in the
> request header below, we see "email@example.com", when, in fact, the
> original request had "ats@hubert", without any domain name.
Obviously your mailer isn't making a reasonable assumption.
My experience is that this kind of hack just makes it harder to track
down problems. It's much easier to just have all of your local hosts
that speak SMTP spit out fully-qualified domain addresses and have
your mailer leave all addresses alone. That way, when you see an
address of the form firstname.lastname@example.org, you *know* that "somehost"
is one of yours and not someone else's.
> Since our mailer is doing the qualifying, there is no way SmartList, or
> any other list managing software, can know that both the From: or From
> address is wrong, unless they compare them against the address in the
> Message-Id: (if there is one).
Not even then. There's no requirement that the domain in the
message-id be the same as the one in the From field.
The problem isn't in smartlist, it's in your mailer. You should
direct your attention there rather than trying to fix smartlist.
You may think it's reasonable to have your local mailers emit
unqualified addresses. But the protocols weren't written to
accomodate this behavior, so it's no surprise that it doesn't work