On 23 Nov, Fred Morris wrote:
| 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".
But in this case it doesn't need to be standard. Someone interested in
testing for this doesn't need to depend on other servers' behavior, only
those that touch their mail on the receiving end. That it is encoded is
sufficient under the original proposition. This is about testing if it
was encoded on the *receving* end for some reason other than
obfuscation. So, if the receiving server insert some header that
uniquely identifies its handiwork, and excepting software and
configuration changes, there's a predictable pattern to test which only
depends on the local setup -- standard or not.
| [...]
| 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
|
Not impugning your artwork - but what a rat's nest!
--
Reply to list please, or append "8" to "procmail" in address if you must.
Spammers' unrelenting address harvesting forces me to this...reluctantly.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail