Date: Wed, 09 Aug 2017 20:18:42 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 210537] [patch] [feature request] set MIME type in cron-generated e-mails Message-ID: <bug-210537-8-uUCXrc8V37@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-210537-8@https.bugs.freebsd.org/bugzilla/> References: <bug-210537-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210537 Eugene Grosbein <eugen@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eugen@freebsd.org --- Comment #5 from Eugene Grosbein <eugen@freebsd.org> --- While the intention is good and proposed feature would be useful, the solution has are some rough edges. First, it's not very flexible to implement this as global option. You could easily make it per-crontab depending on environment variable like CONTENT_TYPE. Cron already looks at per-crontab MAILTO environment variable, why not look at CONTENT_TYPE? Then, cutting contents at first 1024 bytes embedded in the code is error-prone. Note well: libmagic has MAGIC_PARAM_REGEX_MAX==8192 currently. I'd suggest "CONTENT_TYPE=libmagic:1024" format when ":1024" part would be optional to redefine default of MAGIC_PARAM_REGEX_MAX. Also, I would not be so sure about "Content-Transfer-Encoding: 8bit" header. 8bit does not mean "any data". According to RFC 2045 https://www.ietf.org/rfc/rfc2045.txt , it means short (998 octets or less) text strings without null bytes and CR/LF octets in CRLF sequences only. If the body contains binary data, the "binary" Content-Transfer-Encoding token must be used. Mentioned PNG would violate "8bit" for sure. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-210537-8-uUCXrc8V37>