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
