Hello Frank, thank you for your response.
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. --------------------------------------- Would you please be kind enough to propose a patch for the file do_command.c, which implements encoding and attaching big outputs? 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. Thank you in advance for your response. Best regards, Georges. Frank Heckenbach a écrit : > Hello, > > > I am the new maintainer for cron package, since a few months. Please can > > one elaborate a little longer about use cases where too long lines are a > > problem? > > Thanks for picking up this issue again. I'm not the original > reporter, but also effected, as I wrote in my comment last year. > > SMTP standards (RFC 2822) specify a maximum line length of 998 > characters. > > It can be avoided by encoding the mail. QP (quoted-printable) and > base64 are common encdings. QP can break source lines (by inserting > "=\n" anywhere), and base64 output doesn't care about line breaks at > all. > > > Would it be sufficient to truncate such lines to 998 characters, hoping > > that such a length would be sufficient to diagnose a problem? > > This would lose information. I don't think I'd like this unless the > original content was stored somewhere and the mail contains a link > where to find it. But that seems more work than the alternatives. > > > It would > > be more secure than splitting them and making it possible to overflow > > the file system (for example with too big messages, repeated every > > minute during one day). > > Overflowing the file system is a separate issue which can just as > well happen with many short lines. Sure, you might want to handle > this too, but for that you'd might want to set a maximum size (say, > in MB and perferably configurable) independent of line lengths. > > Regards, > Frank -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: PGP signature
