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=3D210537 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 solut= ion 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_T= YPE. 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-pr= one. Note well: libmagic has MAGIC_PARAM_REGEX_MAX=3D=3D8192 currently. I'd suggest "CONTENT_TYPE=3Dlibmagic: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. --=20 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>