Don Hammond wrote:
On 23 Nov, Nancy McGough wrote:
| On 23 Nov 2002 dman(_at_)nomotek(_dot_)com (dman(_at_)nomotek(_dot_)com)
wrote:
| > Don Hammond <procmail(_at_)tradersdata(_dot_)com> wrote:
| >
| > > I don't want to speak for Dallman, but the recipe is not searching the
| > > body. The thinking on the filter seems to be, if it's plain text or html
| > > AND base 64 encoded, then it's spam. There would be no reason, I guess,
| > > to encode plain text other than to circumvent content filters. Who does
| > > that? The bottom feeders.
| >
| > Exactly. Thanks, Don.
|
|
| I don't think it's just the bottom feeders that do this. If a
| message contains a high ascii character, such as the GB Pound
| symbol, and the mail client or the mail transport only does 7bit,
| then the message will be MIME encoded, either with
| quoted-printable or base-64. I think that Mulberry and Cyrus IMAP
| server always convert to 7bit and thus always encode messages
| with 8bit characters (and this is one of the few things I don't
| like about these products). I think there are other clients and
| servers that do this too.
[...] But
wouldn't it be typical for the server to add a header if the encoding
was done locally? In my saved mail there are X-MIME-Autoconverted:
headers indicating conversions done by my server (sendmail). [...]
In the ecology of MTAs, gateways may transform messages is to be
interpreted as an admonition to assume they will, where as the fact that
any MTA may transform a message is to be interpreted as a warning that any
MTA may consider itself a gateway. The fact that the header you refer to
starts with X- should be sufficient warning not to rely on it as a
"standard".
While 8-bit ASCII has been tolerated, strictly speaking 822 and especially
2822 restrict the content of message bodies to 7-bit. There is an extension
to SMTP (1652) which supports the transport of 8-bit; 2822 does not
obsolete 1652. In this case, the willingness to receive 8-bit content is
negotiated at the time that the SMTP connection is established, and the
receiving host can either accept or reject such content; if it rejects it,
the sending host may convert it to 7-bit, or it may treat it as a delivery
failure.
The header which indicates the encoding is Content-Transfer-Encoding. This
header may be present in the message headers if the body is not composed of
at least one MIME part. If the body is composed of MIME parts, then the
header may occur with each atomic MIME part; if not present, the type is
assumed to be text/plain (2045).
If you find yourself needing to wade through the large number of RFCs which
touch on this stuff, you may find this document useful:
http://www.inwa.net/~m3047/procmail/rfc-tree.pdf
or, you may not!
--
Fred Morris
m3047(_at_)inwa(_dot_)net
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail