I have several headless systems doing useful work around the place:-
A Raspberry Pi providing local DNS and DHCP
A Beaglebone Black on our boat monitoring temperatures and batteries
An old desktop doing backups in the garage
etc.
Most of these have one or more cron jobs running periodic rsync backups, copying data, etc. If the cron job has an error then it sends E-Mail to the owner of the job ('chris' in most cases, might be root in a couple).
It's (moderately) easy to set up an MTA and /etc/aliases so that the messages are sent to my normal E-Mail. However I can't come up with a straightforward way of indicating where the messsage is *from*.
You can't just invent a domain name for the headless system because that gets the E-Mail rejected by intermediate systems that try and look up the sender host name. Cron doesn't seem to have any mechanism for setting the sender's name, cron errors just come from 'root@'.
Can anyone suggest a neat way of handling this so that I know where the errors are coming from?
On 17/02/17 10:33, Chris Green wrote:
I have several headless systems doing useful work around the place:-
A Raspberry Pi providing local DNS and DHCP A Beaglebone Black on our boat monitoring temperatures and batteries An old desktop doing backups in the garage etc.
Most of these have one or more cron jobs running periodic rsync backups, copying data, etc. If the cron job has an error then it sends E-Mail to the owner of the job ('chris' in most cases, might be root in a couple).
It's (moderately) easy to set up an MTA and /etc/aliases so that the messages are sent to my normal E-Mail. However I can't come up with a straightforward way of indicating where the messsage is *from*.
You can't just invent a domain name for the headless system because that gets the E-Mail rejected by intermediate systems that try and look up the sender host name. Cron doesn't seem to have any mechanism for setting the sender's name, cron errors just come from 'root@'.
Can anyone suggest a neat way of handling this so that I know where the errors are coming from?
Use SSMTP and set up the config file properly...
Cheers, Laurie.
On Fri, Feb 17, 2017 at 11:10:33AM +0000, Laurie Brown wrote:
On 17/02/17 10:33, Chris Green wrote:
I have several headless systems doing useful work around the place:-
A Raspberry Pi providing local DNS and DHCP A Beaglebone Black on our boat monitoring temperatures and batteries An old desktop doing backups in the garage etc.
Most of these have one or more cron jobs running periodic rsync backups, copying data, etc. If the cron job has an error then it sends E-Mail to the owner of the job ('chris' in most cases, might be root in a couple).
It's (moderately) easy to set up an MTA and /etc/aliases so that the messages are sent to my normal E-Mail. However I can't come up with a straightforward way of indicating where the messsage is *from*.
You can't just invent a domain name for the headless system because that gets the E-Mail rejected by intermediate systems that try and look up the sender host name. Cron doesn't seem to have any mechanism for setting the sender's name, cron errors just come from 'root@'.
Can anyone suggest a neat way of handling this so that I know where the errors are coming from?
Use SSMTP and set up the config file properly...
I looked at SSMTP but it doesn't seem to be maintained and I can't see how to set the sender name either.
As I said above setting the domain doesn't help because the domain used has to be a real domain which intermediate mail servers can look up to check. So I can't just set the domain to rpi.isbd.co.uk because there isn't any such domain.
If one could set a default From: line like:- From: Rasberry Pi root@isbd.co.uk
that would do the necessary but I can't see how to do it.
On Fri, Feb 17, 2017 at 11:58:34AM +0000, Chris Green wrote:
On Fri, Feb 17, 2017 at 11:10:33AM +0000, Laurie Brown wrote:
On 17/02/17 10:33, Chris Green wrote:
...
It's (moderately) easy to set up an MTA and /etc/aliases so that the messages are sent to my normal E-Mail. However I can't come up with a straightforward way of indicating where the messsage is *from*.
You can't just invent a domain name for the headless system because that gets the E-Mail rejected by intermediate systems that try and look up the sender host name. Cron doesn't seem to have any mechanism for setting the sender's name, cron errors just come from 'root@'.
Can anyone suggest a neat way of handling this so that I know where the errors are coming from?
Use SSMTP and set up the config file properly...
I looked at SSMTP but it doesn't seem to be maintained and I can't see how to set the sender name either.
As I said above setting the domain doesn't help because the domain used has to be a real domain which intermediate mail servers can look up to check. So I can't just set the domain to rpi.isbd.co.uk because there isn't any such domain.
If one could set a default From: line like:- From: Rasberry Pi root@isbd.co.uk
that would do the necessary but I can't see how to do it.
Exim on Debian uses /etc/email-addresses to determine how to expand local address for outgoing mail. Perhaps that might help?
J.
On Fri, Feb 17, 2017 at 12:06:51PM +0000, Jonathan McDowell wrote:
On Fri, Feb 17, 2017 at 11:58:34AM +0000, Chris Green wrote:
On Fri, Feb 17, 2017 at 11:10:33AM +0000, Laurie Brown wrote:
On 17/02/17 10:33, Chris Green wrote:
...
It's (moderately) easy to set up an MTA and /etc/aliases so that the messages are sent to my normal E-Mail. However I can't come up with a straightforward way of indicating where the messsage is *from*.
You can't just invent a domain name for the headless system because that gets the E-Mail rejected by intermediate systems that try and look up the sender host name. Cron doesn't seem to have any mechanism for setting the sender's name, cron errors just come from 'root@'.
Can anyone suggest a neat way of handling this so that I know where the errors are coming from?
Use SSMTP and set up the config file properly...
I looked at SSMTP but it doesn't seem to be maintained and I can't see how to set the sender name either.
As I said above setting the domain doesn't help because the domain used has to be a real domain which intermediate mail servers can look up to check. So I can't just set the domain to rpi.isbd.co.uk because there isn't any such domain.
If one could set a default From: line like:- From: Rasberry Pi root@isbd.co.uk
that would do the necessary but I can't see how to do it.
Exim on Debian uses /etc/email-addresses to determine how to expand local address for outgoing mail. Perhaps that might help?
Thank you! :-)
That took me to *exactly* what I need, postfix has a similar parameter (and I'm much more familiar with Postfix):-
smtp_generic_maps (default: empty)
Optional lookup tables that perform address rewriting in the Postfix SMTP client, typically to transform a locally valid address into a globally valid address when sending mail across the Internet. This is needed when the local machine does not have its own Internet domain name, but uses something like localdomain.local instead.
That description just about encapsulates my problem! ... and provides a solution, I can set the 'From: ' address using this mechanism, I think.
On 17/02/17 11:58, Chris Green wrote:
On Fri, Feb 17, 2017 at 11:10:33AM +0000, Laurie Brown wrote:
[SNIP]
I looked at SSMTP but it doesn't seem to be maintained and I can't see how to set the sender name either.
As I said above setting the domain doesn't help because the domain used has to be a real domain which intermediate mail servers can look up to check. So I can't just set the domain to rpi.isbd.co.uk because there isn't any such domain.
If one could set a default From: line like:- From: Rasberry Pi root@isbd.co.uk
that would do the necessary but I can't see how to do it.
---- cut here ----
# cat /etc/ssmtp/ssmtp.conf # # Config file for sSMTP sendmail # # The person who gets all mail for userids < 1000 # Make this empty to disable rewriting. root=cict-root@convergent-ict.com
# The place where the mail goes. The actual machine name is required no # MX records are consulted. Commonly mailhosts are named mail.domain.com mailhub=smtp.convergent-ict.com:587
# Where will the mail seem to come from? rewriteDomain=###.convergent-ict.com
# The full hostname hostname=###.convergent-ict.com
# Use SSL/TLS before starting negotiation UseTLS=Yes UseSTARTTLS=Yes
# Username/Password AuthUser=###### AuthPass=######
# Are users allowed to set their own From: address? # YES - Allow the user to specify their own From: address # NO - Use the system generated From: address #FromLineOverride=YES
---- cut here ----
That works for me...
Cheers, Laurie.
On Fri, Feb 17, 2017 at 01:23:49PM +0000, Laurie Brown wrote:
On 17/02/17 11:58, Chris Green wrote:
On Fri, Feb 17, 2017 at 11:10:33AM +0000, Laurie Brown wrote:
[SNIP]
I looked at SSMTP but it doesn't seem to be maintained and I can't see how to set the sender name either.
As I said above setting the domain doesn't help because the domain used has to be a real domain which intermediate mail servers can look up to check. So I can't just set the domain to rpi.isbd.co.uk because there isn't any such domain.
If one could set a default From: line like:- From: Rasberry Pi root@isbd.co.uk
that would do the necessary but I can't see how to do it.
---- cut here ----
# cat /etc/ssmtp/ssmtp.conf # # Config file for sSMTP sendmail # # The person who gets all mail for userids < 1000 # Make this empty to disable rewriting. root=cict-root@convergent-ict.com
# The place where the mail goes. The actual machine name is required no # MX records are consulted. Commonly mailhosts are named mail.domain.com mailhub=smtp.convergent-ict.com:587
# Where will the mail seem to come from? rewriteDomain=###.convergent-ict.com
# The full hostname hostname=###.convergent-ict.com
# Use SSL/TLS before starting negotiation UseTLS=Yes UseSTARTTLS=Yes
# Username/Password AuthUser=###### AuthPass=######
# Are users allowed to set their own From: address? # YES - Allow the user to specify their own From: address # NO - Use the system generated From: address #FromLineOverride=YES
---- cut here ----
Well when I did similar, e.g. I did the equivalent of:-
rewriteDomain=###.convergent-ict.com hostname=###.convergent-ict.com
The E-Mail was rejected by the TSO smarthost saying that ###.convergent-ict.com isn't a valid domain.
On 17/02/17 13:32, Chris Green wrote:
On Fri, Feb 17, 2017 at 01:23:49PM +0000, Laurie Brown wrote:
On 17/02/17 11:58, Chris Green wrote:
On Fri, Feb 17, 2017 at 11:10:33AM +0000, Laurie Brown wrote:
[SNIP]
Well when I did similar, e.g. I did the equivalent of:-
rewriteDomain=###.convergent-ict.com hostname=###.convergent-ict.com
The E-Mail was rejected by the TSO smarthost saying that ###.convergent-ict.com isn't a valid domain.
As Mark pointed out, you need to be able to reverse lookup that domain name and receive an IP address back. I manage my own DNS on my own servers, so no issue for me.
Cheers, Laurie.
On Fri, Feb 17, 2017 at 02:13:11PM +0000, Laurie Brown wrote:
On 17/02/17 13:32, Chris Green wrote:
On Fri, Feb 17, 2017 at 01:23:49PM +0000, Laurie Brown wrote:
On 17/02/17 11:58, Chris Green wrote:
On Fri, Feb 17, 2017 at 11:10:33AM +0000, Laurie Brown wrote:
[SNIP]
Well when I did similar, e.g. I did the equivalent of:-
rewriteDomain=###.convergent-ict.com hostname=###.convergent-ict.com
The E-Mail was rejected by the TSO smarthost saying that ###.convergent-ict.com isn't a valid domain.
As Mark pointed out, you need to be able to reverse lookup that domain name and receive an IP address back. I manage my own DNS on my own servers, so no issue for me.
Yes, I *could* set up a zone file to have the domain name in it (e.g. I could set up rpi.isbd.net for the pi and bbb.isbd.net for the Beaglebon) but it seems like a sledgehammer to crack a nut as a solution to the problem.
On 17/02/17 14:44, Chris Green wrote:
[SNIP]
Yes, I *could* set up a zone file to have the domain name in it (e.g. I could set up rpi.isbd.net for the pi and bbb.isbd.net for the Beaglebon) but it seems like a sledgehammer to crack a nut as a solution to the problem.
Not really. It will take a couple of minutes at best, and then you can forget about it. I really don't understand the problem. It is also the correct solution, and not some half-arsed fudge involving loads of gmail addresses, and all the effort of reading them and monitoring them. I use filters in Thunderbird to sort the incoming email into folders under the same account, by the sending server name in the header.
Cheers, Laurie.
On 17 February 2017 at 10:33, Chris Green cl@isbd.net wrote:
Can anyone suggest a neat way of handling this so that I know where the errors are coming from?
Alternative approach from the others here: Have different destination email addresses for each sender.
We use GMail which allows me to have (say) systems@<my domain>, which then silently maps systems+<anything>@<my domain> into the same mailbox, so that's how we do it; systems+Pi1@..., systems+boat@... and so on.
But even without Gmail doing it for me, setting up the mapping at the server end to map multiple recipients into one mailbox whilst still allowing you to filter based on the different "recipients", rather than the different "senders", should be straightforward. It slightly complicates the server end but massively simplifies the configuration at the sender end.
On Fri, Feb 17, 2017 at 03:34:53PM +0000, Mark Rogers wrote:
On 17 February 2017 at 10:33, Chris Green cl@isbd.net wrote:
Can anyone suggest a neat way of handling this so that I know where the errors are coming from?
Alternative approach from the others here: Have different destination email addresses for each sender.
We use GMail which allows me to have (say) systems@<my domain>, which then silently maps systems+<anything>@<my domain> into the same mailbox, so that's how we do it; systems+Pi1@..., systems+boat@... and so on.
But even without Gmail doing it for me, setting up the mapping at the server end to map multiple recipients into one mailbox whilst still allowing you to filter based on the different "recipients", rather than the different "senders", should be straightforward. It slightly complicates the server end but massively simplifies the configuration at the sender end.
Yes, that is one way of doing it that I've considered. It requires me to set up new mailboxes (or at least forwarders) for the new destination mail addresses but I can do that easily enough.
I was just hoping for a simpler way! :-)