There's no explanation for the problem you're reporting unless $PATH when running that script from whatever method you're using (not the CLI itself) lacks /bin in its path. I would suggest using fully-expanded path names for all utilities, i.e. /bin/date, /bin/nvram, and so on. It may be that $PATH contains another date utility (such as in /opt/bin) that does not support -R or --rfc-2822 flags. Alternately you could use /bin/date +"%a, %d %b %Y %T %z" to get the same output as -R, and that will work consistently across multiple *IXes and date commands.

Your script also has other issues, such as lack of space after the double-quotes surrounding the real name but before the bracket of the Email address. In fact, your script isn't going to work at all with that bug.

I would also suggest you stick the contents of your backtick commands into variables at the top, rather than do them inline, i.e. date="`/bin/date -R`" and wanip="`/bin/nvram get wan_ipaddr`" then refer to them in the rest of your script via $date and $wanip.

Finally, please stop using /tmp/mail.txt as the filename. Use something more random, such as /tmp/mail.txt.$$ ($$ will get expanded to the PID of the /bin/sh instance). I.e. do tmpfile="/tmp/mail.txt.$$", then use $tmpfile therein. You should also use /bin/rm -f to remove the file rather than just rm.

I don't think you understand SMTP correctly, sadly. For Email clients' sakes, those need to be From: and Date:. You also need an extra newline after the SMTP headers and the actual content of the mail. There's absolutely no reason using colon after those words would tickle any problem. You should also be quoting variables whenever possible (you've moved the variable expansion outside of the quotes for reasons I do not understand), and you've also got slashes in front of $tmpfile for no good reason (this will get expanded to //tmp/mail.txt.$$ which will work but it's awful habit).

You know, there's an easier way to do this that you probably aren't familiar with, which is called a heredoc. Hell, why don't I just write the script for you.

And I can confirm this works fine. If you want to see it work yourself, change the tmpfile assignment to a static location (i.e. /tmp/mail.txt) and remove the $sendmail and $rm calls at the end, then see the file in /tmp yourself.

Okey, well I give it a try and I must confess I'm not a programmer. Thank you for your patient.
I have tested your script and date isn't displayed in my mail client " Thunderbird"
kthaddock

Click to expand...

Sorry, my mistake (and in two ways). Please change the line to:

Code:

date="`/bin/date +'%a, %d %b %Y %T %z'`"

This should address the issue. (Yes, welcome to quoting hell -- this is one of the biggest problems with shell scripts. Backticks, double-quotes, and apostrophes all in one. The quoting order matters as well.)

The quoting order matters too, by the way. For example if you were to swap the apostrophes and backticks, you'd end up with $date containing the literal string /bin/date +"%a, %d %b %Y %T %z", which obviously isn't what you want.

And if backtick ever bothers you, you can use $( and ) instead, i.e. date="$(/bin/date ...)".

Look very closely there. You'll see the From:, To:, Subject:, and Date: headers all there in the SMTP header section. The Date: header is where/how your Email client determines when the Email was sent to you.

If you want the actual date inside of the body of the message, you can put it somewhere after the blank line. It all depends on what you want, but you should still keep it in the SMTP header section too. The only exception to this rule is that you should not use the word "From" (without a colon, and case-sensitive) at the start of a line inside the body of the message.

And just to make it crystal clear: the two Date: lines you see there are intentional. The first one is part of the SMTP header (as I showed you), the other is part of the body of the message. Note that I also added the To: header; I should have done that from the get-go, sorry about that.

The order of the headers doesn't matter either, so if you wanted to put the first Date: entry above From: (to make it easier to understand/read/etc.) that'd be fine.

Doesn't the Busybox sendmail applet take care of inserting the SMTP headers? That's why I only inserted the body entries (Date/From/Subject) when I wrote the original sample script. Unless the sendmail applet merely accts like a straight MTA, expecting you to provide all the headers.

So it appears to add the To: SMTP header itself, but the rest of the SMTP headers are up to the user to provide via stdin.

Be sure to understand that the -f argument is what defines the SMTP MAIL FROM envelope header (the first line you see, re: "From ... " -- note lack of colon), which does not have to be the same thing as what's in the From: SMTP header. SMTP envelope != SMTP header.

Basically the above would translate to the following SMTP conversation:

Based on what I can tell, the /usr/sbin/sendmail binary acts as an idiot middle-man at the TCP level for communicating with an SMTP server. Quite literally as you issue commands to it via stdin, it feeds those directly to the SMTP server it has a TCP connection to. It appears to have some basic understanding of SMTP status codes too. If you give it an Email address the remote SMTP server returns an SMTP 5xx status code for, it rejects it right then and there. Take a look:

The "bad recipient" message is coming from /usr/sbin/sendmail itself, but it's a result of my SMTP server (icarus.home.lan) returning relay access denied (because my router is not in my permitted list of IPs/hosts which can send mail through it):

The reason there's two "bad recipient" errors -- #1 comes from issuing the To: SMTP header, which /usr/sbin/sendmail obviously converts into the RCPT TO SMTP command, so that gets rejected (relay access denied). #2 comes from after I sent EOF (Ctrl-D), which is where the SMTP server again sent back the same SMTP response (relay access denied) before the socket was closed/QUIT issued.

So basically, there's no need to include the To: line in the script itself -- the argument on the command-line will cause /usr/sbin/sendmail to do the right thing. I didn't know that until now.

TL;DR -- /usr/sbin/sendmail is a cheap/crappy TCP-focused MTA. "It works", but I can now see why/how people get incredibly confused by its behaviour.