Dillon Cron sends the output of a cronjob to the user, but it fails to create a
valid mail file causing the xmail sendmail to not accept the mail file, which
means the users do not get cronjob output in their mail boxes. It creates
headers like this:
Subject: cron: <cronjob>
The 'To:' field is not valid according to RFC 2822, because a addr-spec has to
look like 'local-part "@" domain'. Since dcron does nothing with the MAILTO=
part in a cronjob, the only way to solve this problem is by changed the source,
job.c in this case. The attached patch changed the header to:
Subject: cron: <cronjob>
While this is not the best solution (which, imo, would be the support of MAILTO
in a cronjob) at least this way the mail will be accepted by xmail's sendmail.
The mail server should be able to redirect the mails to another mailbox if
needed (fe some other domain).
NOTE: It is possible that the created mail file is accepted by sendmail's from
other MTAs than XMail.
Steps to Reproduce:
1. Install dillon cron (sys-process/dcron)
2. Install XMail (mail-mta/xmail)
3. Create a cronjob that produces output
The mail that dcron tries to send is not accepted by sendmail.
The mail should have been accepted by sendmail.
Created attachment 68937 [details, diff]
Patch to make the mail header valid
MAILTO is an env var right ? how about something like:
(getenv("MAILTO") != NULL ? getenv("MAILTO") : file->cf_User)
I have no extensive knowledge about crondaemons, but AFAIK since you specify the
MAILTO inside a crontab, it is parsed by the crond itself, so it is not an env
var, unless the crond exports it (but why would it).
maybe even a better solution would be a daemon parameter --domain which can be
used to specify what domain it has to use (localhost, qtea.nl), and if this
parameter is moitted it sends mail to <user> like it normally does... but since
that is more than just a bug fix it has to be discusses/proposed to the author
Matthew Dillon / development crew ?
I'm fighting with exactly the same problem.
It would seem that traditional cron will use the ENV var "MAILTO", but also pick up any MAILTO= lines in the crontab itself.
It would seem that dcron simply ignores the MAILTO= lines in the crontab, and, if I read the code in your patch directly, it in fact does not use the MAILTO ENV var either, but instead always sends the output to the user.
Now, often your linux box, especially if it is a server, should be set up for local mail delivery, so this is no problem.
However, for some cases it clearly is problematic, like xmail, or if using ssmtp.
This is especially problematic because ssmtp seems to be the default for desktop gentoo installs.
Since ssmtp provides no way to alias the outgoing email addresses, the cron-output is sent to "username" via SMTP to your provider, who sensibly will drop the bad address as undeliverable...
Any ideas if dcron will ever be fixed in this regard? This bug was posted almost 4 years ago now...
Created attachment 184588 [details, diff]
Patch to make mail header valid
Reading over RFC2822, the origination date and from fields are required. As discussed, the address requires an '@', and the date must also be a certain spec.
This patch accomplishes these requirements. Please test! I am also forwarding to the author.
is this also a problem with other MTAs as well?
it is correct that an email in an SMTP session must be fully qualified, but in the case of a cron giving a mail to an MTA, shouldnt the MTA do hostname expansion?
sounds like a bug in xmail to me...
in any case: hardcoding it to @localhost is not better.
Sorry to reply 7 months later -- I never CC'ed myself to the bug, and the issue moved to the backburner. It moved back to the frontburner because I recently changed my MTA setup.
(In reply to comment #6)
> is this also a problem with other MTAs as well?
ssmtp and esmtp seem to function okay, because you can set either to rewrite root's emails to another address. (In ssmtp, use "root=<your email>" in ssmtp.conf.)
> it is correct that an email in an SMTP session must be fully qualified, but in
> the case of a cron giving a mail to an MTA, shouldnt the MTA do hostname
At least esmtp is capable of local delivery, and assumes that addresses without "@" in them are local and hands them off to the local mail delivery agent (e.g., procmail). However, this is not in RFC 822 as AFAICT.
> sounds like a bug in xmail to me...
The problem is not limited to MTA's like xmail. Many mail readers also assume RFC 822 compliance. If your cron logs get sent out to GMail and then retrieved from it via POP or IMAP, the message will be compliant. However, if your local MTA is just doing local delivery, it does not make the header compliant if it's not so to begin with.
I currently use local delivery, and use Evolution as my mail reader. Evolution cannot display my dcron emails without my patch above.
> in any case: hardcoding it to @localhost is not better.
Indeed, this may cause problems. As I wrote above, esmtp assumes that an email address without "@" is for local delivery. Unfortunately, it also assumes that any address with "@" requires an SMTP connection, even "@localhost". Unless you are running a local mailserver this fails.
But this behavior is not RFC 822 compliant, either. The problem is that the email spec assumes email servers; local relay-only MTAs are a hack. The latest release of esmtp, version 1.1 (not yet in portage) can be forced to dump all emails locally to procmail. This requires a patch for correct "-t" option handling ...
I have heard from neither the dcron nor esmtp maintainers about my patches :P
is this still valid with latest version?
I'm still using address rewrite in ssmtp to get my root emails via gmail, so can't test directly. However, looking at the source for dcron-4.5 in 'job.c', the mail header it provides is still not RFC2822 compliant. On the other hand, one can now specify a mailto address on the command line and specify which mailer to use. Thus, one should be able to work around an invalid 'To:' address, and work around RFC2822 compliance by wrapping a problematic mailer with a script that makes the headers acceptable.
I am unsure about the advantages of using dcron over other maintained alternatives like cronie. I saw that most major distributions stopped to provide dcron, and upstream looks dead, hence, likely bugs won't ever get fixed.
I was then even considering to treeclean it and make people to migrate to better maintained alternatives :/