cyrus-8bit-2.3.3.diff nonsense (Cyrus Patches used at FastMail.FM)

[Greg A. Woods]

At Sat, 27 May 2006 11:56:38 +1000,
Robert Mueller wrote:
> 
> >> Comments on the non-local ones:
> >> - cyrus-8bit-2.3.3.diff
> >
> > Was it not the position held by CMU in the last five years or so that one
> > such patch would *have* do to it properly and re-encode the header to some
> > default charset, in order not to corrupt the store with lack of charset
> > information (for searches) ?
> >
> > Or am I getting completely confused, here?
> 
> I think having this as an *option* is perfectly reasonable. There are 
> already other imapd options like rfc2046_strict and rfc3028_strict that 
> control some strictness of RFC behaviour.

Just for the record I don't think that a run-time option should be
considered in this case, especially not in the case of a site like an
ISP which must deal with international mail.  This isn't anything like
those other two cases, and especially not the latter one.

> In this case it seems to me the options are:
> 1. Reject the message

This is the only sane thing to do.  It's actually not that hard at all
to explain to people that their other ISP is offering sub-standard
service by accepting provably corrupt messages and that by doing so they
may even be making it easier for the bad guys to cause direct damage to
the customer's own systems and data should they download such corrupt
messages.  It might be FUD-like, but it works.

Maybe it's OK for internal-only systems which never see incoming
messages from the real world and which have their own brain-dead but
uniform way of dealing with non-standard encodings.  If a site really
wants to blindly ignore these issues then they can hack and patch their
own custom code to allow it.

I.e. if this feature really must be an option for those who can deal
with the idiocity then it should be an _undocumented_ internal
compile-time only option; and those who turn it on without even further
patching should suffer from having their stored messages identified to
their users as being potentially corrupt with some additional header
text.

> - users hate loosing email just because it's not fully 
> RFC compliant, especially when "my other provider doesn't have a problem"

Also for the record:  sites which do allow their users to get away with
using broken mailers which generate corrupted messages should be warned
that their users may find it increasingly difficult to deal with growing
numbers of other sites which will not accept their user's corrupt
messages.  I.e. those lame sites may eventually have to deal with the
issue anyway -- it's not going to go away on its own, especially not
where the sites in question don't also control all the software that
users might use on their own computers.

-- 
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>       Secrets of the Weird <woods at weird.com>