[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: switching from exim to postfix

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.


[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;

Reply to: