On Tue, Sep 19, 2023 at 05:48:01PM +0200, Ingo Schwarze wrote: > Hi Walter, > > i did not look closely at the patch yet, and i did not dig for standards > documents, which one should almost certainly do before committing such > a patch unless one knows all the relevant standards by heart (which i > do not), so i'm not saying this must be done differently, but instead > i am merely asking questions.
Today I came from having a biopsy of a tumor that appeared in my leg in "February" of this year and thanks to the bureaucracy and the fact that nowadays nobody takes anything seriously, I still don't know if the tumor is malignant. The apathy and irresponsibility of the people (especially here in Spain) is such that I am thinking of buying a scalpel and operating my tumor myself. I explain this because, you can't imagine, dear Ingo, how happy it would make me if at least 10% of the people in this world were half as responsible as you are. :-) > > 1. Are you really sure that a header like > MIME-Version: 1.0 > is not needed when you add Content-*: headers? > > 2. Are you really sure that a header like > Content-Disposition: inline > is not needed? Thanks for the info. :-) > > 3. What is the reason for not simply hardcoding > Content-Transfer-Encoding: 8bit > when sending UTF-8 mail? Yeah, I thought about it. > Are there really still MTAs that choke on that in 2023? > quoted-printable is definitely a PITA no matter the context, > so in my book, if it can be avoided, avoiding it would be a plus. I always try to choose what, from my ignorance, I suspect will cause the least problems. In this case I take into account that when sending a file to the Internet its health no longer depends only on what *my system* supports or not, out there it'll have to survive different environments. Many people still send messages in iso-latin and use MSWin which still doesn't use utf-8: I send a message utf-8 encoded and I get the response in iso-latin. So, from my ignorance, I feel that ASCII has more chances of surviving. > > 4. What's the motivation for the -y flag taking an argument > and not simply hardcoding "text/plain;charset=utf-8"? I also thought about that. > OpenBSD does not support any other charset and does not plan to > change that in the future. > I hope your next patch isn't going to be support for text/html. =:-S Believe me, I try to do everything in my life in the simplest way, while others allow me. But as with everything you have to be careful not to overdo it, for example, in the case that concerns us here, if you notice that every time you need some job done you have to install and use the bloated version of the tools, you should ask yourself if you haven't gone too far with your simplifications. I'm more in favor of the traditional "Keep it simple..." and "If ain't broken..." rather than "simplifying". Simplifying is dangerous, amputating a leg simplifies your body as a system but not your life. > > 5. What's the motivation for supporting -y without -e > and for supporting -e without -y ? Right, that's an inconsistency. > > In general, we want as few options as possible and as little > configurabity as possible. If there is a sane use case for something - > in this case, sending UTF-8 mail - *one* option is possibly warranted. > But adding more than one option would need a very robust justification, > and so would adding an option that takes an argument. > > Note that mail(1) is not mail/swaks. Its purpose is reading and > sending mail in a *simple* way, not low-level testing or protocol > debugging. > > I'll postpone code review and testing, maybe you can simplify this > first? Well, as you have done with me on many occasions, your intention is to kindly educate me, on this occasion you're making me notice that publishing "sketches" instead of a finished work I'm wasting the developers' time. Thanks Ingo! What saddens me is that I'm too old to hope that one day I will win your approval in something. :-) > > Yours, > Ingo -- Walter
