Alan is begging for this, off-topic, and perhaps confusing
to most people -- see my short dictionary at the end for
the unfamiliar acronyms I use :-)
Not so easy, in fact if the MTA does it, it is a layering
violation... (I will elaborate on this below.)
Furthermore, I can easily envision rather many cases where
I want to have receive several messages with same message-id.
Those don't happen, you say ?
My system-wide uniqueness-criteria would need at least:
- "Message-Id:" -line
- "From:" -line
- envelope mail-from address
- envelope rcpt-to address
Consider a message sent "To: linux-kernel", "Cc: linux-smp",
and all phases of processing while the MTA at VGER feeds
message to Majordomo (twice! once for each list), and then
does list-address expands.
Even then things might reject something that I have once
send to somebody, and now want to re-send it from my sent
messages archive to the same address, but I use MUA "b"
(bounce) command for it, which sends out the message with
those RFC-822 headers already present -- giving exactly
same set of stuff as was in my original message.
(The MUA is supposed to fill in the message-id, after all.
Most MTAs are doing message-id production as a favour, but
to be exact, those are violating layering. Same story
applies also to "From:" header that some MUAs don't
bother to fill in.)
(Sure, with proper MUA I can't do that, as such does kosher
"Resent-To:", "Resent-From:", and so forth conversions for
the pre-existing headers before creating new MSGID/From/To
headers, but we ELM die-hards don't use kosher MUAs...)
> Another easy solution is qmail's X-Loop: header. It just adds an
> 'X-loop: listname' header to every outgoing message and when it sees
> such a header from the outside it discards the message. Very simple
> and seems to work well.
People become confused with qmail, it combines MTA and MS/MUA
functionality in surprising ways. Although the same is true with
sendmail, as with any other MTA software these days. In slightly
different forms perhaps, but all of them violate the IFIP model.
qmail's list handling systems with "X-Loop:" trinkets are MUA
functionality. I think Majordomo could do it, but it is not
MTA's function. (qmail "X-Loop:" works by having each list
processing/message redirecting entity to see, if there exists
"X-Loop:" with same address that caused the lattest expansion
processing to occur -- at VGER such line could be:
"X-Loop: linux-kernel@vger.rutgers.edu"
When no such line can be found, no "X-Loop:" header shall be
removed from the expanded header set.)
Overall, UNIX sendmail model of doing things does not match
in obvious ways with IFIP Messageing Model (which latter became
known as basis of X.400) (No, I am not THAT old, I just know
my history ;-) )
In all practical systems the users can ask the MTA to perform
certain tasks on user's behalf that really belong to MUA. Lets
call such things Auto-MUA. In essence, in UNIX world there is
no single MUA that people use, rather there exists a colourfull
collection of programs; eveybody can have a system pleasing
their taste in GUI gadgets -- and non-GUI ones..
Of these Auto-MTA things especially the .forward to a new
address (not to local programs/files) violates the IFIP
messageing model in the sendmail (and ZMailer) implementations,
mainly because it is handled by the routeing facility, and
not by the message-store delivery/auto-MUA facility.
Not that most X.400 systems behave in any sensible way
at it either...
The .forward should modify the transport envelope source
address into something that (in case of an error) will cause
error reports to be delivered to the failure site, and not
to somewhere else who might not be able to do anything..
Consider linux-kernel list owner's problem when somebody has
a subscription on address A, and then .forwards his/her email
from address A to address B, and the address B bounces back to
the list owner instead of going to somebody at site A..
Now think of B bounceing back to linux-kernel list; you have
many angry people out of whom very few are email-wizards and
able to track address A out...
A short dictionary for you:
MTA Message Transport Agent; software moving email in between
systems. These are "mailers" (in my dictionary anyway)
MS Message Store; at its simplest form: /var/mail/, but
it can be a lot more complex beas with highly complex
access protocols (consider IMAP)
MUA Message User Agent; programs that users use to manipulate
email, and many auto-MUAs: mailx, Mail, elm, pine, mush,
mh, Eudora, procmail, Majordomo, ... For most people,
the word "mailer" is used to refer to these gadgets, Sigh..
> -Andi
/Matti Aarnio <matti.aarnio@tele.fi> <mea@vger.rutgers.edu>
Looking after MTA things at VGER ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu