On Wed, Jul 25, 2012 at 08:58:32PM +0200, Matthias Apitz wrote: > El d??a Wednesday, July 25, 2012 a las 12:49:31PM -0400, Mark E. Mallett > escribi??: > > > On Wed, Jul 25, 2012 at 04:39:21PM +0200, Matthias Apitz wrote: > > > El d?a Wednesday, July 25, 2012 a las 09:44:47AM -0400, Mark E. Mallett > > > escribi?: > > > > > > > > Are you putting in a Mime-Version header field, or is that getting > > > > stripped too? (I don't see it in the example you appended) > > > > > > No, should we? > > > > Yeah, if you are using any MIME header fields you should have the > > MIME-Version field too (see RFC2045). > > We have not set any MIME header fields, only Content-type;
Content-Type is a MIME header field, per the RFC I mentioned. Also, go here: http://www.iana.org/assignments/message-headers/perm-headers.html find Content-Type, which refers you to RFC 4021; go there, find Content-Type, which refers you to RFC 2045; which tells you that you need a Mime-Version header field :) > I checked the source of the resulting mail and se now that UTF-8 coded > chars are represented like this, an "?" is arriving as "=C3=BC"; this is > not what we wanted, even if the MUA can show them fine; but what about other > software reading such mails? I'd prefer plain UTF-8 body. Well, as a gross generalization: it looks like it's doing a quoted-printable content-transfer-encoding, which it's allowed to do in order to convert 8-bit data (or any bytes, really) to something more palatable to its context or configuration. An MTA shouldn't be accepting raw 8-bit without negotation, though some do, and it's free to change the encoding when it e.g. talks to another MTA or to a delivery agent. In other words, you as a sender may not get to have a say as to how the receiver or any intermediate MTA encodes it. All rather far afield from mutt, though. mm
