> From: Alan Stebbens <firstname.lastname@example.org>
> > > 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.
> The point of using list mgr software is so that I, the human, am not
> involved unless absolutely necessary. Of course, I can handle it;
> you're missing the point.
No, by "reasonable list manager" I was referring to software.
> > Of course, this won't work if you insist that people only subscribe by
> > sending mail from the address that they're subscribing to.
> The subscription succeeded, actually, because the given address on the
> command was correct, despite the fact that originating mail had
> unqualified hostnames.
good. (did smartlist send a copy of the acknowledgement to the
address that was subscribed? if so, what's the problem?)
> Where do you infer that I am insisting that people only subscribe with
> their originating address?
I didn't infer this. The "this won't work..." was a just-in-case.
It's hard to guess what kind of policies people might have in place.
> However, it is customary for most mailers to form a return address from
> one of the originating headers, and SmartList is no different -- it
> accepted the correct address from the command line, but it responded to
> (or tried to) a return address formed from the "Reply-to" or "From"
(aside: It turns out that you really want this to go to the envelope
return address. I wrote na-net to send acks to the header reply
address, and it turned out to be a losing approach.)
again, it's a good idea for a list manager program to send a copy
of the ack to the person who's subscribed. That way if person A
subscribes person B, person B finds out *why* he's getting all of
this mail he didn't ask for...
> > > 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.
The assumption isn't reasonable because it's not true.
> This is neither obvious nor unreasonable. In an arbitrary context, a
> central mailer, when given a plain name, has no other choice except to
> assume that it is qualified in the local domain.
False. It can certainly leave the headers alone. And if the sender's
mailer doesn't know its own domain for the HELO or MAIL FROM command,
it's perfectly reasonable for the SMTP server to bounce it. This way
the problem gets detected (and fixed) immediately, and you don't
get the wierd failures that happen when mailers rewrite header addresses.
> With unqualified
> originating addresses, it may not be necessary to qualify them, but
> neither will they be of any use for future replies.
True. But since replies don't work at all, you'll find the problem
fairly quickly. If you try to patch things up at the central mail
server, it works most of the time, but when it fails, the failure
is detected at the recipient site (like the failure you detected)
and the person who detected the failure can't do much about it.
(e.g. you can't do much to fix ats@hubert's mailer...)
The problem is that not all of the traffic that goes through your
MTA is locally-originated. If someone sends mail to an address
at your machine, and the mail gets forwarded to another domain,
the sender's address will get rewritten by your machine.
> All of our local hosts are configured to fully qualify the hostname.
I guess it depends on what you mean by "local hosts".
> Why, then, one might ask, does your mailer fully qualify unqualified
> hostnames? The answer is because our mailer serves as a campus
> mail-hub, guaranteed to emit properly formatted mail. Many
> departments, especially those without technical support, rely on this
> hub mailer to take their POP-based mail (from their Macs or PCs), and
> "clean it up" before sending it onward.
Yes, but you cannot reliably "emit properly formatted mail" that
wasn't formatted correctly in the first place, because you cannot
tell mail that is broken because it came from one of your campus
(see, I didn't say "local") brain-dead POP clients, from mail
that is broken because it came from somebody else's broken mailer.
It might seem like your approach wins because, after all, most
of the mail you rewrite is locally originated. But if you look
instead at the number of mailer errors you track down (and how much
time you spend doing so), my guess is that you spend more time
tracking down remote errors. So you want to minimize the number
of errors you cause for others...which implies that you want to
detect your local errors as soon as possible.
> > The problem isn't in smartlist, it's in your mailer. You should
> > direct your attention there rather than trying to fix smartlist.
> I disagree. The real problem is the particular originating host which is
> issuing plain addresses. The solution is to remove the offending address
> from the list, until mail from it uses properly qualified names.
I think there are three problems:
1) your list subscriber's mailer which is spitting out bad from addresses.
2) the "Macs and PCs" on your campus that emit bad from addresses.
3) your mailer, that tries to fix (2) and ends up fixing some problems
and making others worse.
If I were in the position of trying to make this work, I'd probably
hack sendmail to append default domains to header addresses *only*
for SMTP traffic from the local subnets that are used by PCs
and Macs. This would work fine in practice as long as none of the
hosts for which you do the rewriting ever accept incoming mail and
forward it elsewhere (which would be true for POP hosts that don't
run an SMTP server).
It may seem like I'm carping, but I've spent a lot of time looking
at this problem, and I've concluded that all of this "fixing up"
just ends up making the whole mail system less reliable. Of course
you're going to do what you have to to keep the mail running,
but it's worth the effort to make sure that what you're doing
doesn't botch 3rd party mail.