"-f '<>'" breaks with several sendmail implementations

[hannob]

I just noticed that a cron service on a server hasn't sent out user cron mails for quite a while. The server is running the courier mail server.

It appears that this started with cronie 1.7.0, due to this change: https://github.com/cronie-crond/cronie/commit/d5d7db6a42f8c3ae6f6bd1efc767ae3fe97f4734

This sets "-f '<>'" by default. Previously, the default was to set "-f [username]". Apparently, courier does not accept '-f <>' and produces a syntax error.

Apparently, this change was reverted: https://github.com/cronie-crond/cronie/commit/4e8c767efb1bea03da465fee29641b65da1246eb

However, right after that another change was committed that is effectively doing the same thing in a different way: https://github.com/cronie-crond/cronie/commit/c640f4f39e5c20995e960e4b954cd0574a96c028

So now it's broken again. This could be mitigated only by having a MAILFROM in all user crons, but this appears to be a major hassle and a change of how cron has worked for decades, I do not think this is a desirable solution.

I'm not sure if the sendmail "interface" is standardized anywhere, and if courier is also at fault here. But reporting this here first to get some clarification.

I would strongly recommend to revert this change. If the option to set "-f '<>'" is needed, this should at the very least be configurable and probably standard off so it does not break existing setups.

[t8m]

I am disappointed nobody reported this earlier than just after I released 1.7.1.

Anyway, patches making this optional are welcome, but I am not going to revert this again.

[steffenweber]

I've just noticed that emails sent by cronie are not delivered anymore since updating to cronie 1.7.0 because our relay (Amazon SES) refuses to accept them:

Jan 19 09:57:00 zen1 postfix/smtp[3507969]: 57B85260541: to=<test@example.org>, orig_to=<username>, relay=email-smtp.eu-central-1.amazonaws.com[18.156.57.233]:587, delay=0.14, delays=0/0/0.14/0, dsn=5.0.0, status=bounced (host email-smtp.eu-central-1.amazonaws.com[18.156.57.233] said: 501 Invalid MAIL FROM address provided (in reply to MAIL FROM command))

Edit: IMHO this is a BC break that I would not have expected in a "Minor bug fix and enhancements release" and the workaround (adding a MAILFROM entry to all crontab files?) seems tedious and error-prone.

[hannob]

I tried to understand this better, and it seems very clear that the change that caused this should never have been done in the first place and is a bug for multiple reasons.

Using "-f '<>'" to send a mail with an empty envelope from address appears to be an undocumented feature of some sendmail implementations. It is neither documented in the original sendmail man page, nor in the postfix one. It works in postfix's sendmail (sometimes?), but that appears to be a coincidence. It causes a syntax error in courier, and an error mail in exim. So, from three sendmail implementations I have tested, it only works in one.

There's also no reason why it should work. The parameter to "-f" is a username or an e-mail address, so if anything, an empty envelope header would be "-f ''". The diamond brackets '<>' are used around mail addresses in the raw SMTP protocol as passed to "MAIL FROM:", but they are not part of the mail address itself (e.g., for test@example.com, you would pass "-f test@example.com" and not "-f test@example.com").

Furthermore, the whole change goes against RFC recommendations. An empty envelope-from address, called a "null reverse-path" in the SMTP spec, has a special meaning in the SMTP protocol. It is meant for notification messages of the SMTP protocol itself, like Delivery Status Notifications etc.

The SMTP specification in RFC 5432 states: "All other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path." ( https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.5 )

I would therefore ask you to revert this change.

[t8m]

OK, reverted. I've made MAILFROM to be inherited from the process environment, so it is possible to override it globally to allow @odenbach to still use an empty envelope address in his use case.

[hartwork]

For anyone else curious, the two fixing commits are:

• aeb3f8a9cbc0da7e6367d41a2b769eb7e90855f3
• 6181605fafe6aaedc0c19a8bdc85a335403b42d8