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

[Simon Matter]

> 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.

Cyrus is not only used with ISPs. It's also used in the corporate world
where other rules exist.

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

Stop, are you joking? Did you ever work in the corporate world? Did you
ever have a boss in a large international company? Did you ever tell him
that the server you installed _rejects_ mail?

> to explain to people that their other ISP is offering sub-standard

And if the other one is not an ISP but your important customer?

> 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

And if the "bad guys" are your customers who in the end pay you?

> the customer's own systems and data should they download such corrupt
> messages.  It might be FUD-like, but it works.

Maybe you want to fix the customers mail system for free, do you? You say
it works, but hey, it doesn't work for all of us.

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

Ah, what you are talking about is the real wold? No, it's just a part of a
quite large world. It's all a question of your point of view.

> 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.

Or they can enable an option in the config file. What's wrong with the
option?

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

Undocumented feature is the M$ way, do you want that? No sorry,
_undocumented_ is just stupid and evil.

> 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.

Did you ever explain some thousand of normal users what email headers are?
Believe me, it's not easy. However, your idea is not bad, do you have a
patch?

>
>> - 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.

Unfortunately the problem is not going away anyway, with or without
cyrus-8bit-2.3.3.diff patch. However, the patch is a good solution for
some users of cyrus-imapd and I just don't understand why it's such an
issue of discussion now. My congratulations to Ken, who has had a good
feeling for the situation when he decided to accept the patch!

Simon