Hello Georges, > thank you for your response.
I was busy otherwise recently. I suppose, this is still open, isn't it? > cron is a key command for UNIX systems, and it is supposed to remain > lightweight and efficient. This is why it does not implement the mailing > features, and relies on other UNIX commands to do this job (`mail` or > `sendmail`) > > You can browse the file do_command.c in cron's source package, and read, > near line 360, how cron does its job to collect data coming from > children commands, and compose an e-mail. > > So far, the output of the child command is just appended to a text > stream, which begins with From:, To:, Subject:, Date: lines. However you > are searching to address the case when the output of the command is too > big to be just appended to such a text file. > > In the case of a big output, the solution would be to encode it (QP or > base64 are possible encodings), but in such a case, they should not be > appended to the same stream which contains From:, To:, Subject:, Date: > lines, but included in a separate stream, and handed to `send` or > `sendmail` command as an attachment. Not necessarily an attachment. They can be appended to the stream, provided that the Content-Transfer-Encoding header is set appropriately, which would have to be done retroactively when we encounter long lines. However, when reading the code, I noticed that cron uses 8bit transfer encoding by default, but already accepts the environment variable CONTENT_TRANSFER_ENCODING and passes it through to the mail header, but without doing any encoding itself. So this only works if the cron command's output is already encoded which seems strange. I don't know how people use this option (and I guess neither do you?). Maybe it's just a relic from back when cron used 7bit by default, so it was needed for any non-ASCII output at all. Anyway, given that this variable exists, perhaps we can add a special value, say "auto", which cron would turn into some encoding (I'd suggest quoted-printable). So if the environment variable is set to some other value, nothing will change, but if set to "auto", it will put QP in the header and do QP encoding itself. This would be backward-compatible. However, it would require everyone who's affected by this problem to put something like "CONTENT_TRANSFER_ENCODING=auto" in their crontab, and in a few years, people will wonder why such a silly thing is required. We could go one step further and make "auto" the default. I *think* these days every mail client should support QP, but you never know (https://xkcd.com/1172/). In any case, those who want the old behaviour could still get it by setting "CONTENT_TRANSFER_ENCODING=8bit". So that would be a transparent bugfix, but not 100% backward-compatible, and may require action by (I hope) just a few users. What do you think? > --------------------------------------- > > Would you please be kind enough to propose a patch for the file > do_command.c, which implements encoding and attaching big outputs? I think I can write the code. Fortunately, QP is not too complex and rather easy to implement on the fly without any dependencies. > If you can do it, I would be very pleased to read your code and include > your patch to the series of patches which are part of the debian source > package, in order to create this new feature. > > By the way, if you modify the way cron sends e-mails, please can you > propose a simple test to check whether your modification is running as > expected? This test will be appended to the series used in autopkgtest, > in order to prevent eventual future regressions. Unfortunately, I'm not familiar with the test framework. I can certainly provide some crontabs and expected mails, but I'd have to leave it to you to integrate them. Regards, Frank
