On 04. mai 2012 01:29, Roger Lynn wrote:
On 02/05/12 02:00, brian m. carlson wrote:On Tue, May 01, 2012 at 07:47:08PM +0100, Roger Lynn wrote:I have enabled accept_8bitmime in every exim I've installed for the last 10 years and no one has reported any problems. I think the risk of encountering a truly 7 bit MTA in this decade is low enough to be ignored for most purposes. Anyone still using one is likely to find that a substantial fraction of their incoming mail is corrupted.I actually use Sendmail's strict 8BITMIME support to help catch spam. I agree that 7-bit MTAs are essentially gone, but with the volume of spam I receive, I set my mail software to be extremely strict with regard to protocols. Legitimate software (of any sort) generally generates protocol-compliant messages. Malicious and illicit software (and that created by Microsoft) generally does not. Legitimate software also generally has a userbase that will complain about rejected data if the software is not protocol-compliant, which often leads to fixes. I've complained to the listmasters that they send 8-bit data that is not MIME (virtually all of which is spam) under the auspices of the 8BITMIME extension; they refuse to fix this, and as a consequence they have to deal with the occasional piece of undeliverable mail. This is not a knock against the listmasters, just an observation that if you violate the protocols, some places will reject your data.Many MUAs have options for sending 8 bit mail[0]. Do they take notice of whether the MTA they're talking to is 8 bit capable? It will be a while until I have a chance to experiment. Roger [0] For example, in Iceape: "For messages that contain 8-bit characters, use 'quoted printable' MIME encoding. Leave unchecked to send the messages as is.
I had a hell of a time getting gmail to accept my dkim signed messages. SOME, not all, were being rejected. Google thought they had been tampered with. Turns out my mail-client sends pure text mails with Content-Transfer-Encoding: 7bit if I don't use any "8bit characters", but it still puts in charset iso8859-1. Whenever my smarthost provider (using qmail I believe) found a message with this impossible combination it "helpfully" changed the headers. Don't remember which way they shifted them.
I had to put the code below (perl) in the dkimproxy.out script at an appropriate point:
----
if(defined($content_type) &&
defined($content_transfer_encoding) &&
($content_type =~ m(text\/plain)i) &&
($content_type =~ m(charset=iso-8859-1)i) &&
($content_transfer_encoding =~ m(7bit)i)){
...
$content_transfer_encoding =~ s(7bit)(7BIT)i;
$content_type =~ s(charset=iso-8859-1)(CHARSET=US-ASCII)i;
...
}