On Tue, 2012-10-30 at 02:06 +0100, Matthias Andree wrote: > (I am aware of Wietse's reply to the message I am quoting.) Yeah... so ongoing discussion on the issue itself is rather pointless, nevertheless...
> > Well quoted printable encoding is of course a way around this, but > > similarly as you have no guarantee that a client/tool > > understands/expects e.g. mboxrd, you have no guarantee that a mail that > > postfix receives was composed by a client that does this quoting, right? > > Either you choose the argument in your favour or contradiction - but use > it consistently. Meaning that: Either you make assumptions on the > client software's capabilities (regardless of whether you require a > particular handling of From_-stuffing, or MIME), or you do not. I do not quite get your point... all I tried to say was, clients working around the issue by using quoted printable is no guarantee for "globally" solving it (simply because not all clients do it and it's not demanded by the RFCs)... it's a "good to have", IMHO, but ultimately the software taking care on storing the data (in this case the mail) is usually responsible for doing this in a correct manner... > No, but reinventing the wheel whilst ignoring existing solutions, or > trying guerilla standardization, are no such ways either. > > As stated earlier, there is no single established mbox flavour, and has > not been for nearly two decades. > > Acknowledging there is no consensus, every hard-wired change between > mbox flavours will please one group and inconvenience another group. ... now we agree probably all that, as well as no one can't force all the world to move away from mboxo to mbox<??>... and of course it's absolutely clear that the situation with mboxo is not postfix fault... > Incompatibility with documentation - such as local(8) - and existing > Postfix practice of the past sixteen-or-so years. ... all I pointed out was, that there is a solution (mboxrd) which AFAICS should at least not critically break other clients. It will also modify the messages (just as all other mbox formats do) but in contrast to mboxo you have at least a chance to recover. In all doing respect, I personally don't think that documentation that can easily be changed or even decades of practise justify an irrecoverably corruption, especially when the above is true (i.e. that mboxrd would cause no modifications to non-aware clients that were more severe than what mboxo does). Imagine someone finds out, that the glibc pow(3) would wrongly subtract -0.0000000000000000001 from each result in some rare cases. People would expect to have this solved, even if it used to be there for years. One can always argue about what get's a higher priority in such a case, but for my personal opinion none of the arguments brought up so far (including the two of yours) can justify irrecoverable mail corruption. Anyway... in the ends it's the maintainer who decides, arguments or not, which has happened. > The delivery agent is the right place to deal with delivery issues such > as output formats Sure, but isn't local(8) just that? A delivery agent? > you will have to allow > the question held up against you what technical reason there is NOT to > use Maildir. Sure... - you waste a lot of storage with maildir[0] - maildir is slower in some cases, like full text search - people might have tools or clients that only support mbox (of course they may be still prone to the issues resulting from the different subformats) But IMHO, technical questions are not the only thing that matters here. Analogously to my pow(3) example,... you wouldn't want to have this function not fixed, just because the problem was widely known and everyone can easily program his own mypow(), would you? > You have not answered that one, either on the > fetchmail-users list, nor on the postfix-users list, yet. Well I though these, were obvious to most people on both lists :) Anyway... not sure yet whether/when I have time to look into postfix' code to see how easy it was to add an option for the mbox format and support for at least mboxrd. I guess Wietse also rejected my other initial suggestion of at least documenting it more clearly any emphasised in the documentation, that mboxo is used and the issues it has. At least on a short glance over the local(8) manpage, I couldn't find anything like this. Cheers, Chris. [0] if you're looking for some real world numbers: http://dovecot.org/pipermail/dovecot/2012-October/069130.html
smime.p7s
Description: S/MIME cryptographic signature
