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@xxxxxxxxxxx> Planix, Inc. <woods@xxxxxxxxxx> Secrets of the Weird <woods@xxxxxxxxx> ---- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
