procmail
[Top] [All Lists]

Re: Simplifying Mime messages

2002-11-23 17:08:59
Don Hammond wrote:
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.
| >|
| >|
| >| [...]If a
| >| message contains a high ascii character, such as the GB Pound [...]
| >
| >[...] 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). [...]

I'm not sure the encoding is being done locally. It may be being required
locally.

| 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.

The point of the above is that it should be encoded on the *sending* end,
not the *receiving* end... *if* 1652 ESMTP 8BITMIME is being used. OTOH
maybe sendmail on your end is accepting it as-is, and blithely deciding
that having done so it will in any case do what 2822 calls for, which seems
to be what you're asserting. I don't know, but there'd be no good reason
for it to do so: it could legally use ESMTP on the way out, and then fall
back if the next hop balks. Maybe that's what's actually happening.

I am not certain that that entirely invalidates the underlying assumptions
in practice; it might have some bearing on interpretation of observed
behavior when you're getting it to work, however, or in understanding why
in some cases it doesn't.

| [...]
| 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!


LOL! Yeah, what does reading all of those do to your mind!!?? 8-~

Let alone writing them.. Heffalumps, pheromones, infinite monkeys,
recommendations that people advertising false root should be shot... read
enough RFCs and you'll find that and more.

--

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