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;
...
}
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fa3b3b6.2070...@alstadheim.priv.no