No problems with any of the below, just some comments.
On 28 Nov 1996, Jason L Tibbitts III wrote:
> resend:
>
> The virtual Majordomo hack went in, but it really should be configurable,
> especially since it doesn't seem to work:
>
> #!/usr/local/bin/perl5
> $whereami="virtual.com";
> $opt_l="fvwm";
> $a="To: fvwm\@sina.hpc.uh.edu";
> $a =~ s/^to:(.*)\b$opt_l\b(.*)$/To:$1 $opt_l\@$whereami $2/i;
> print "$a\n";
>
> produces:
>
> To: fvwm@virtual.com @sina.hpc.uh.edu
>
> A test message to my ends up with the same kind of breakage. $opt_l does
> _not_ contain the hostname, and even if it did, it just won't handle things
> like this, which I see all the time:
>
> To: fvwm@sina.hpc.uh.edu mailing list <fvwm@hpc.uh.edu>
>
> I really don't think this was thought through well enough. Arbitrarily
> rewriting headers (especially an address header, which can have so many
> possible formats) is really difficult to get right, and one line isn't
> going to do it. Plus, I already have Sendmail putting my headers in
> canonical domain-only format; I don't need Majordomo trying to do it
> again. People using virtual domains should really discuss this.
>
Sendmail is not rewriting the To: header which Majordomo sends to
it for delivery. This is specifically ruled out by resend. Check
for lines (~470-480) in resend beginning with the comment
# check for the dreaded -t option to sendmail, which will cause
This is evidenced by the fact that members of a Majordomo mailing
list do not receive messages address to them directly, ie the To:
header does not read "To: list_subscriber@subscribers.domain".
Majordomo could rewrite the To: header to a completely invalid e-mail
address and it would still get delivered. That's because sendmail
is being invoked such that message recipient is expected to be found
on the command-line as an argument. [Since sendmail isn't even looking
in the To: header for recipients it can't rewrite it.] See the top of
resend, lines 52-67, and line 468.
The To: header only gets rewritten on some systems, *before* the
message is received by Majordomo. Those familiar with their MTA
or lucky enough have their systems configured to leave the header
alone (and as such the incoming domain is preserved in its original
form and not translated into the localhost's name).
Some of our list-owners were wondering why the domain name for
their organization "worked" for messages going into the list, but
did not appear in the messages resent out to members of the list.
In fact, the "change" of address confused some of the list members.
I looked into using resend_host for this purpose, but quickly
found that alone wasn't going to solve the problem.
Obviously, the To: header which is sent out to the list should be
that of a functioning e-mail address. Though the regular expression
above is itself not very general and so a poor choice (and so not the
best thing to include in a release), it was intended to rewrite the
To: header to a functioning alternative address for the list, at the
"virtual domain". An earlier follow-up of mine on this issue suggested
use of the following, "smarter", expression which is applied to only
those addresses in the To: header in one of two forms:
"listname@local.domain.name"
or just
"listname"
(which accomodates those cases where local domain/hostnames are removed
from the header for whatever reasons). Here's the follow-up suggestion
which I haven't myself had time to test (sorry..) properly:
$locdom = '@local.domain';
$_ =~ s/^to:(.*[,\s])\b$opt_l[$locdom]?([,\s].*)$/To:$1 $opt_l\@$whereami $2/i ;
$_ =~ s/^cc:(.*[,\s])\b$opt_l[$locdom]?([,\s].*)$/Cc:$1 $opt_l\@$whereami $2/i ;
So if the list is addressed as listname@local.domain followed by a comma
or a space then change the address to reflect the domain in $whereami as
configured by the majordomo-owner for the list. Likewise, if the
list is addressed "listname" followed by a comma or a space (no "@"s),
then also set the address to "listname\@$whereami". (The question mark
requires that exactly zero or one occurence of the string in $locdom
appears.) The header should be left alone in all other cases. I think
this covers the range of possibilities when the virtual domain fix/hack
should be applied. [Perhaps the value of $hostname as contructed in
majordomo is the same as $locdom above.]
Allowing this to be toggled on or off by a list config variable is still
a good idea. Afterall, in cases where it's not needed or desired, why
bother using the code?
Ok, I'm hungry,
-Ajay.
Follow-Ups:
References:
|
|
