My phpinfo() shows different values than the ones I've set up in my php.ini, I'm on Manjaro Deepin.
This is what phpinfo() shows:
sendmail_from no value no value
sendmail_path -t -i -t -i
serialize_precision 100 100
short_open_tag On On
SMTP localhost localhost
smtp_port 25 25
This is what the php.ini file looks like:
[mail function]
; For Win32 only.
; http://php.net/smtp
SMTP = smtp
; http://php.net/smtp-port
smtp_port = 587
; For Win32 only.
; http://php.net/sendmail-from
sendmail_from = exchange_shop#uniwa.gr
; For Unix only. You may supply arguments as well (default: "sendmail -t -i").
; http://php.net/sendmail-path
sendmail_path = /usr/sbin/sendmail -t -i
Any ideas why?
Related
I need to configure a service to on Oracle application server to test connectivity with database and then send an email notification about status. Can anyone help me please.
Thanks,
Here's one option:
TNSPING database you're interested in
evaluate the result (you're interested in the last line)
send the result by e-mail
A few remarks:
tnsping %1 > ping_result.txt pings database passed as a parameter (%1) and stores the result into a .txt file
middle part of a script is modified code written by #Aacini (you'll see a link)
finally, mailing the result is done by bmail (you can use any other command line SMTP mailer; or, Google for "bmail download" - it is free)
Here you go:
rem PING_DB.BAT
#echo off
setlocal EnableDelayedExpansion
tnsping %1 > ping_result.txt
rem Littlefoot slightly adjusted code: https://stackoverflow.com/questions/27416341/how-can-i-read-the-last-2-lines-of-a-file-in-batch-script
rem Tail command in pure Batch, version 2: Tail.bat filename numOfLines
rem Antonio Perez Ayala
set /A firstTail=1, lastTail=0
for /F "delims=" %%a in (ping_result.txt) do (
set /A lastTail+=1, lines=lastTail-firstTail+1
set "lastLine[!lastTail!]=%%a"
if !lines! gtr 1 (
set "lastLine[!firstTail!]="
set /A firstTail+=1
)
)
for /L %%i in (%firstTail%,1,%lastTail%) do set result=!lastLine[%%i]!
rem end of LF's adjustment
echo %result%
echo off
bmail -s smtp.server.name -f tnspinger#me.com -t my_real_mail#gmail.com -a "%result%" -c
bmail's options:
Command Line SMTP Emailer V1.07
Copyright(C) 2002-2004 Craig.Peacock#beyondlogic.org
Date: Wed, 20 Jun 2018 10:08:15 +0200
Usage: bmail [options]
-s SMTP Server Name
-p SMTP Port Number (optional, defaults to 25)
-t To: Address
-f From: Address
-b Text Body of Message (optional)
-h Generate Headers
-a Subject (optional)
-m Filename (optional) Use file as Body of Message
-c Prefix above file with CR/LF to separate body from header
-d Debug (Show all mail server communications)
Testing (I've removed bmail's output):
M:\>ping_db xe
TNS-12541: TNS:no listener --> this is being sent by e-mail
M:\>ping_db orcl
OK (10 msec) --> this is being sent by e-mail
I am trying to run tshark in a perl script, simply by doing the following -
my $filter = "port 68 or 67";
my $capture = "tshark -i eth0 -f $filter -a duration:120 -w pcapture.pcap&";
system($capture);
This code is not starting the tshark process. Any changes recommended?
Assuming port 68 or 67 is a legal value for -f, you need quotes to treat it as one entity (a value which contains whitespace):
my $filter = "port 68 or 67";
my $capture = "tshark -i eth0 -f '$filter' -a duration:120 -w pcapture.pcap&";
system($capture);
PHP's mail function seems to deliver mail on a clean system, with no apparent configuration done by the administrator or webmaster (no SMTP configuration in php.ini, etc.). How does the mail function deliver mail to a remote server?
On *nix it invokes the sendmail binary, which then uses the mail configuration to route the email. On Windows, it sends to a SMTP server. In both cases the sysadmin sets up the mail system.
You can detect how it works as below.
First method
$ ltrace php -r "mail('tester#127.0.0.1', 'Test', 'Hello world');" 2>&1 | grep sendmail
memcpy(0x095ea168, "sendmail_from", 14) = 0x095ea168
memcpy(0x095ea1e0, "sendmail_path", 14) = 0x095ea1e0
popen("/usr/sbin/sendmail -t -i ", "w") = 0x0977c7c0
From the results of the above command can be seen that the popen() function opens the process of /usr/sbin/sendmail -t -i.
$ ls -l /usr/sbin/sendmail
... /usr/sbin/sendmail -> exim4
So sendmail is the symbolic link to exim4 and hence sendmail -t -i invokes exim4 -t -i.
And in the manual page of exim4 you can read about these options -t -i:
$ man exim4 | grep ' -t -i'
-ti This option is exactly equivalent to -t -i. It is provided for compatibility with Sendmail.
Second method
Install snoopy and run:
# grep snoopy /var/log/auth.log | tail
... php -r mail('tester#127.0.0.1', 'Test', 'Hello world');
... /usr/sbin/sendmail -t -i
... /usr/sbin/exim4 -Mc 1YxxYn-0006a7-Nw
... /usr/sbin/exim4 -t -oem -oi -f <> -E1YxxYn-0006a7-Nw
... /usr/sbin/exim4 -Mc 1YxxYn-0006aB-Oj
The results of the above command show the sequence of the commands which were performed.
mail() uses sendmail, that uses DNS to find MX record of target domain and delivers there directly. thats it.
and since destination server probably does not know your ip address, especially if it is NATed it may be marked as spam.
you can modify your config to use different (legit ad known) smtp server to act as intermediary.
It's really not that reliable, actually, unless the underlying sendmail or something is properly configured.
Amazon SES has better servers than whatever server you're using and gets mail there more times than with mail().
The real reason you shouldn't use mail() is because your server's IP address is probably completely unknown to mail services such as GMail, Yahoo, etc, and there is a higher chance it will get marked as spam. Why does it get marked as spam? Because mail() is very easy and simple to exploit for spam purposes.
Okay, I want to have Nmap scan an IP range for computers with a certain port open (port 80 in this case) and have it output all the IP's it finds into a text file, stored in this format:
192.168.0.1
192.168.0.185
192.168.0.192
192.168.0.195
So to output the file, I tried using this command:
nmap -sT -p 80 -ttl 40 192.168.0.0-255 -oG - | grep "80/open" > output.txt
Where "output.txt" is the output file that contains the results. So a line of output.txt looks
like this:
Host: 192.168.0.1 () Ports: 80/open/tcp//http///
So I basically want it only to output the IP address with port 80 open, and nothing else.
I want it to not output the "Host: " or the "()" and "Ports: 80/open/tcp//http///" lines. So is there anyway I can have Nmap not put that stuff into the output file? Or make it only
output the IP addresses? I tried looking at the map page, it was of little help. And I looked all over the Internet and that wasn't very useful either. So does anyone know how I can do this? Thanks
Awk is your friend!
$ nmap -sT -p 80 192.168.0.0/24 -oG - | awk '/ 80\/open/{print $2}' > output.txt
This will find lines with port 80 open (notice the space before 80, if you plan to scan more than the one port!), and print field 2, splitting on whitespace. Another way to do it would be:
$ nmap -sT -p 80 --open 192.168.0.0/24 -oG - | awk '$4=="Ports:"{print $2}' > output.txt
This one uses the --open argument to Nmap to only produce output for hosts with open ports. The awk command checks that this is a "Ports" line, not a "Status" line (which may only show up when using -v, but I'm not positive) before printing the IP address.
Note that it is usually in your best interests to save the scan results to a file, to avoid needing to repeat the scan if you decide to extract some different information. If you choose to do this, I would recommend using the XML output (-oX), since there are lots of analysis tools that have parsers built for it already.
Having nmap produce exactly what you want would indeed be nice. But as a more general solution:
$ nmap ... | grep ... | tr '/' ' ' | awk '{ print $2,$5; }
192.168.0.1 80
Or maybe:
nmap ... | grep ... | tr '/' ' ' | cut -d' ' -f2,8
I found a script called scanreport.sh very useful. Although its not necessary, you could just use awk as suggested, but thought it might be of interest.
It gives the ability to output the nmap results nicely by service or port (with highlighting). It uses the grep-able output from nmap (-oG) after a quick tidy from grep -v ^# nmapoutput.txt > report.txt
Example
nmap -sS 192.168.1.22 -oG /directory/of/choice/results.txt
grep -v ^# results.txt > report.txt
./scanreport.sh -f report.txt
Host: 192.168.1.22 ()
22 open tcp ssh OpenSSH 5.3p1 Debian 3ubuntu4 (protocol 2.0)
80 open tcp http Apache httpd 2.2.14 ((Ubuntu))
./scanreport.sh -f report.txt -p 80
Host: 192.168.1.22 ()
80 open tcp http Apache httpd 2.2.14 ((Ubuntu))
./scanreport.sh -f report.txt -s ssh
Host: 192.168.1.22 ()
22 open tcp ssh OpenSSH 5.3p1 Debian 3ubuntu4 (protocol 2.0)
Plenty of stuff on google about it but here a link to one ref.
./scanreport.sh
I have a script that runs on cron that outputs some text which we send to the 'mail' program. The general line is like this:
./command.sh | mail -s "My Subject" destination#address.com -- -F "Sender Name" -f sender#address.com
The problem is that the text generated by the script has some special characters - é, ã, ç - since it is not in english. When the e-mail is received, each character is replaced by ??.
Now I understand that this is most likely due to the encoding that is not set correctly. What is the easiest way to fix this?
My /usr/bin/mail is symlinked to /etc/alternatives/mail which is also symlinked to /usr/bin/bsd-mailx
I had to specify myself the encoding in the mail header. (The -S is not supported here.)
cat myutf8-file | mail -a "Content-Type: text/plain; charset=UTF-8" -s "My Subject" me#mail.com
You're right in assuming this is a charset issue. You need to set the appropriate environment variables to the beginning of your crontab.
Something like this should work:
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
Optionally use LC_ALL in place of LC_CTYPE.
Reference: http://opengroup.org/onlinepubs/007908799/xbd/envvar.html
Edit: The reason it displays fine when you run it in your shell is probably because the above env vars are set in your shell.
To verify, execute 'locale' in your shell, then compare to the output of a cronjob that runs the same command.
Re-Edit: Ok, so it's not an env var problem.
I am assuming you're using mailx, as it is the most common nowdays. It's manpage says:
The character set for outgoing
messages is not necessarily the same
as the one used on the terminal. If an
outgoing text message contains
characters not representable in
US-ASCII, the character set being used
must be declared within its header.
Permissible values can be declared
using the sendcharsets variable,
So, try and add the following arguments when calling mail:
-S sendcharsets=utf-8,iso-8859-1
Just to give additional information to KumZ answer:
if you need to specify more headers with the -a switch, feel free to add them up, like this (note the polyusage of -a).
echo /path/to/file | mail -s "Some subject" recipient#theirdomain.com -a "From: Human Name <noreply#mydomain.com>" -a "Content-Type: text/plain; charset=UTF-8"
i've written a bash function to send an email to recipients. The function send utf-8 encoded mails and work with utf-8 chars in subject and content by doing a base64 encode.
To send a plain text email:
send_email "plain" "from#domain.com" "subject" "contents" "to#domain.com" "to2#domain.com" "to3#domain.com" ...
To send a HTML email:
send_email "html" "from#domain.com" "subject" "contents" "to#domain.com" "to2#domain.com" "to3#domain.com" ...
Here is the function code.
# Send a email to recipients.
#
# #param string $content_type Email content mime type: 'html' or 'plain'.
# #param string $from_address Sender email.
# #param string $subject Email subject.
# #param string $contents Email contents.
# #param array $recipients Email recipients.
function send_email() {
[[ ${#} -lt 5 ]] && exit 1
local content_type="${1}"
local from_address="${2}"
local subject="${3}"
local contents="${4}"
# Remove all args but recipients.
shift 4
local encoded_contents="$(base64 <<< "${contents}")"
local encoded_subject="=?utf-8?B?$(base64 --wrap=0 <<< "${subject}")?="
for recipient in ${#}; do
if [[ -n "${recipient}" ]]; then
sendmail -f "${from_address}" "${recipient}" \
<<< "Subject: ${encoded_subject}
MIME-Version: 1.0
From: ${from_address}
To: ${recipient}
Content-Type: text/${content_type}; charset=\"utf-8\"
Content-Transfer-Encoding: base64
Content-Disposition: inline
${encoded_contents}"
fi
done
return 0
} # send_message()
You may use sendmail command directly without mail wrapper/helper.
It would allow you to generate all headers required for "raw" UTF-8 body
(UTF-8 is mentioned in asker's comments),
WARNING-1:
Non 7bit/ASCII characters in headers (e.g. Subject:,From:,To:) require special encoding
WARNING-2:
sendmail may break long lines (>990 bytes).
SENDER_ADDR=sender#address.com
SENDER_NAME="Sender Name"
RECIPIENT_ADDR=destination#address.com
(
# BEGIN of mail generation chain of commands
# "HERE" document with all headers and headers-body separator
cat << END
Subject: My Subject
From: $SENDER_NAME <$SENDER_ADDR>
To: $RECIPIENT_ADDR
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
END
# custom script to generate email body
./command.sh
# END of mail generation chain of commands
) | /usr/sbin/sendmail -i -f$SENDER_ADDR -F"$SENDER_NAME" $RECIPIENT_ADDR
rfc2045 - (5) (Soft Line Breaks) The Quoted-Printable encoding REQUIRES that encoded lines be no more than 76 characters long. For bash shell script code:
#!/bin/bash
subject_encoder(){
echo -n "$1" | xxd -ps -c3 |awk -Wposix 'BEGIN{
BASE64 = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
printf " =?UTF-8?B?"; bli=8
}
function encodeblock (strin){
b1=sprintf("%d","0x" substr(strin,1,2))
b2=sprintf("%d","0x" substr(strin,3,2))
b3=sprintf("%d","0x" substr(strin,5,2))
o=substr(BASE64,b1/4 + 1,1) substr(BASE64,(b1%4)*16 + b2/16 + 1,1)
len=length(strin)
if(len>1) o=o substr(BASE64,(b2%16)*4 + b3/64 + 1,1); else o=o"="
if(len>2) o=o substr(BASE64,b3%64 +1 ,1); else o=o"="
return o
}{
bs=encodeblock($0)
bl=length(bs)
if((bl+bli)>64){
printf "?=\n =?UTF-8?B?"
bli=bl
}
printf bs
bli+=bl
}END{
printf "?=\n"
}'
}
SUBJECT="Relatório de utilização"
SUBJECT=`subject_encoder "${SUBJECT}"`
echo '<html>test</html>'| mail -a "Subject:${SUBJECT}" -a "MIME-Version: 1.0" -a "Content-Type: text/html; charset=UTF-8" you#domain.net
This is probably not a command line issue, but a character set problem. Usually when sending E-Mails, the character set will be iso-8859-1. Most likely the text you are putting into the process is not iso-8859-1 encoded. Check out what the encoding is of whatever data source you are getting the text from.
Obligatory "good reading" link: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
Re your update: In that case, if you enter the special characters manually, your terminal may be using UTF-8 encoding. You should be able to convert the file's character set using iconv for example. The alternative would be to tell mail to use UTF-8 encoding, but IIRC that is not entirely trivial.
use the option -o message-charset="utf-8", like that:
sendemail -f your_email -t destination_email -o message-charset="utf-8" -u "Subject" -m "Message" -s smtp-mail.outlook.com:587 -xu your_mail -xp your_password
I'm a bit late but none of the previous solutions worked for me.
Locating mail command (CentOS)
# locate mail | grep -v www | grep -v yum | grep -v share
# ls -l /bin/mail
lrwxrwxrwx. 1 root root 22 jul 21 2016 /bin/mail -> /etc/alternatives/mail
# ls -l /etc/alternatives/mail
lrwxrwxrwx. 1 root root 10 jul 21 2016 /etc/alternatives/mail -> /bin/mailx
# ls -l /bin/mailx
-rwxr-xr-x. 1 root root 390744 dic 16 2014 /bin/mailx
So mail command is in fact mailx. This helped with the search that finally took me to this answer at Unix&Linux Stackexchange that states:
Mailx expects input text to be in Unix format, with lines separated by newline (^J, \n) characters only. Non-Unix text files that use carriage return (^M, \r) characters in addition will be treated as binary data; to send such files as text, strip these characters e. g. by tr -d '\015'
From man page and:
If there are other control characters in the file they will result on mailx treating the data as binary and will then attach it instead of using it as the body. The following will strip all special characters and place the contents of the file into the message body
So the solution is using tr command to remove those special characters. Something like this:
./command.sh \
| tr -cd "[:print:]\n" \
| mail -s "My Subject" destination#address.com -- -F "Sender Name" -f sender#address.com
I've used this solution with my command
grep -v "pattern" $file \
| grep -v "another pattern" \
| ... several greps more ... \
| tr -cd "[:print:]\n" \
| mail -s "$subject" -a $file -r '$sender' $destination_email