Date: Thu, 26 Oct 2000 03:05:02 -0500 (CDT) From: Don Read <dread@texas.net> To: K.J.Bosschaart@tue.nl Cc: questions@FreeBSD.ORG Subject: RE: MS Exchange server and FreeBSD mailing lists Message-ID: <XFMail.001026030502.dread@texas.net> In-Reply-To: <20001023144816.B51105@wop21.wop.wtb.tue.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23-Oct-00 Karel J. Bosschaart wrote:
>
> I'm getting my mail via a MS Exchange server. I'm fetching it with fetchmail,
> which delivers it to sendmail on my FreeBSD PC. Procmail is filtering it to
> several mailboxes and I read it with mutt.
>
> I subscribed some of the FreeBSD mailing lists and use the "Sender:" header
> to filter them; it's in fact the filter that was mailed couple of months
> ago to the -chat (?) mailing list and I'm very happy with it: simple and
> efficient. However, it turns out that the Exchange server sometimes (in less
> than 10 % of the emails) throws out the "Sender:" header, so the filtering
> fails. I mailed the local helpdesk about it and they say that 'the "Sender:"
> header is not a required header so this is not a bug but by design' and I
> have
> to change my filter.
>
> It seems weird to me that random nukes of mail headers would be normal.
> Anyway, I went back to my old mail address that does not pass the Exchange
> server. No problems anymore! Except for the fact that I don't know how long
> this will be supported by my University.
>
> Can someone tell me where in fact is the faulty behaviour? The use of
> non-required headers by the FreeBSD lists or the 'design' of Exchange?
>
Absolute BS.
From RFC822 :
4.4.2. SENDER / RESENT-SENDER
This field contains the authenticated identity of the AGENT
(person, system or process) that sends the message. It is
intended for use when the sender is not the author of the mes-
sage, or to indicate who among a group of authors actually
sent the message. If the contents of the "Sender" field would
be completely redundant with the "From" field, then the
"Sender" field need not be present and its use is discouraged
(though still legal). In particular, the "Sender" field MUST
be present if it is NOT the same as the "From" Field.
The Sender mailbox specification includes a word sequence
which must correspond to a specific agent (i.e., a human user
or a computer program) rather than a standard address. This
indicates the expectation that the field will identify the
single AGENT (person, system, or process) responsible for
sending the mail and not simply include the name of a mailbox
from which the mail was sent. For example in the case of a
shared login name, the name, by itself, would not be adequate.
The local-part address unit, which refers to this agent, is
expected to be a computer system term, and not (for example) a
generalized person reference which can be used outside the
network text message context.
Since the critical function served by the "Sender" field is
identification of the agent responsible for sending mail and
since computer programs cannot be held accountable for their
behavior, it is strongly recommended that when a computer pro-
gram generates a message, the HUMAN who is responsible for
that program be referenced as part of the "Sender" field mail-
box specification.
and RFC821:
4.5.2. TRANSPARENCY
...
The mail data may contain any of the 128 ASCII characters. All
characters are to be delivered to the recipient's mailbox
including format effectors and other control characters. If
the transmission channel provides an 8-bit byte (octets) data
stream, the 7-bit ASCII codes are transmitted right justified
in the octets with the high order bits cleared to zero.
In some systems it may be necessary to transform the data as
it is received and stored. This may be necessary for hosts
that use a different character set than ASCII as their local
character set, or that store data in records rather than
strings. If such transforms are necessary, they must be
reversible -- especially if such transforms are applied to
mail being relayed.
a search also hits RFC1123 & RFC2076;
* Note the 'must be' and 'critical funtion' phrases.
embrace and extend don'cha know, like a Boa constrictor
will embrace & extend a small rodent
Regards,
--
Don Read dread@texas.net
There are old sailors, and there are foolish
sailors; but damn few old foolish sailors.
---------------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.001026030502.dread>