WelcomeUser Guide
ToSPrivacyCanary
DonateBugsLicense

©2025 Poal.co

467

I have a Pi3B running an older version of Raspbian. Not going to upgrade because there's a lot of stuff I and others have written to take advantage of this particular OS version. It's in the cards at some point, but not now.

I'm using the cron MAILTO= variable to catch and send any errors that jobs generate to myself. However, the cron daemon is adding the user's name to the FROM: address. For example:

user@ address@ mydomain.com

Of course, the mail host is rejecting this primarily because it knows that's not a valid user for the mail relay. (It never gets to the "this is a bad address format" check.) This seems to be the only system service that's doing this. Of course, everything on this one is running System======D.

WTF is going on here? I've disabled cron's MAILTO parameter and just have jobs writing to a log, but I'd like to figure out why it's doing this.

I have a Pi3B running an older version of Raspbian. Not going to upgrade because there's a lot of stuff I and others have written to take advantage of this particular OS version. It's in the cards at some point, but not now. I'm using the cron MAILTO= variable to catch and send any errors that jobs generate to myself. However, the cron daemon is adding the user's name to the FROM: address. For example: user@ address@ mydomain.com Of course, the mail host is rejecting this primarily because it knows that's not a valid user for the mail relay. (It never gets to the "this is a bad address format" check.) This seems to be the only system service that's doing this. Of course, everything on this one is running System======D. WTF is going on here? I've disabled cron's MAILTO parameter and just have jobs writing to a log, but I'd like to figure out why it's doing this.
[–] 2 pts

Is it using postfix or mailx? You can set parameters for both to override the "from" address to make it match something that the relay accepts as well as auth if you want.

If you are using the default postfix it might be worth using mailx since you can set the config in a dot file in the home dir of the user that the cron is running as.

[–] 1 pt

I’m using postfix as a relay for all the machines I have, and yes - I did look at ways of overwriting the sender, although postfix docs all like to claim that it is not the intent of the transfer agent to do that kind of work.

I can’t remember how I got a sendmail binary in there, since the relay and cron are on the same device.

My goal is to understand why before I start making changes that affect other machines besides this one.

[–] 1 pt

I’ve never run into that problem, but I usually redirect cron mail by setting a mail alias for the user running the job. That might be why.

I think cron’s MAILTO setting is only meant for usernames. In Ubuntu 24.04 man 5 cron says this:

If MAILTO is defined (and non-empty), mail is sent to the user so named.

The example there only sets it to a username, not a full email address.

None of that explains why it’s adding the username to the outgoing address though. It should be prepending it to whatever Postfix has myhostname set to.

[–] 0 pt

I did notice that it never really calls out the ability to send mail outside of the local spool, but mailto should work with a fully-qualified email address (and does on every other system I run and have run.)

I have to assume there's some sort of bug in this version of cron when combined with a postfix relay running on the same machine. For now, I just have mailto set to "", and all of the jobs redirected to a file on the network where I just need to remember to look at it once in a while.

I may just remove the mailto variable altogether and see if it dumps mail into the local user spool.

[–] 1 pt

I may just remove the mailto variable altogether and see if it dumps mail into the local user spool.

That’s what I would try right away. If it makes it there try setting an alias for that user.

[–] 0 pt

As long as I can get the information somehow, I should be good.

It has the added benefit of removing all the errors from the mail.log...

Will make some changes later and see what happens.