Re: mx.gnus.org being very strict

[Matthias Andree <ma@dt.e-technik.uni-dortmund.de>]

Miles Bader <miles@gnu.org> writes:

> Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:
>> Is there any difficulty with creating a custom header such as:
>> 
>> To: destination@dd.re.ss
>> Subject: my subject
>> MIME-Version: 1.0
>> Content-Transfer-Encoding: 8bit
>> Content-Type: text/x-patch; charset="utf-8"
>
> I suspect that there is no coherent `charset' for the patch; it's just
> bytes.

Make the Content-Type: application/octet-stream when no information is
available, or text/x-patch; charset="x-unknown".

> Anyway, you know the old rule: be conservative in what you produce,
> and liberal in what you accept.  So yeah, it'd be nice if everyone
> would use lots of headers, but rejecting mail outright because there
> are no mime-headers on 8-bit mail is a bit overly strict.

Well, if they are going to emit ("produce" doesn't seem right) the stuff
they have accepted verbatim, accepting junk means producing junk,
breaking the "conservative in what you produce" part. Gateways, Relays
always face this problem. Accept liberally and emit garbage, or accept
only conforming mail and emit conservatively formatted data.

> It's the MUA and the recipient that are going to have a problem with the
> email, if there is one -- and for the same reason, they're also the best
> placed to judge whether there _is_ a problem.

The standards "mail is 7-bit" have been in effect since 1982 and haven't
changed, so you must not generate a patch that doesn't fit into 7-bit
encodings in the first place (that's what uuencode used to be good for).

If you want to overcome the 7-bit restriction, you MUST follow the
standards, i. e. RFC-2045..2049. Anything outside this is certainly not
"conservative". Only applying the robustness princible to the transports
and not to the source and sink does not count.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95