The post Sender Verify Fail first appeared on Server Sitters.
]]>sender verify fail for steve@domain.com: The mail server could not deliver mail to steve@domain.com. The account or domain may not exist, they may be blacklisted, or missing the proper dns entries.
When someone is trying to send an email from outside of your server to an address inside your server, then it’s because the external server failed to pass the sender verification callout. This means that their mail server is not configured to respond to the verification checks that your server is doing.
To allow mail the mail through from the external server, you can add their server IP to the Sender Verification Bypass IP addresses. This is found in the Exim Configuration Editor (Basic Editor) in the WHM. Any IP addresses you add to this will no longer require sender verification, so their mail should go through without any problems
The post Sender Verify Fail first appeared on Server Sitters.
]]>The post Gmail flagging all of your mail as spam first appeared on Server Sitters.
]]>In a cPanel update, they added the following option to the server
disable_ipv6
If this is not disabled, and your server has an IPv6 IP address bound to it, then Exim will send email out using that IPv6 address. So if you do not have the IPv6 address in your SPF record, then Google will see this as an unauthenticated email, and flag it as spam.
There are two ways to correct this.
To turn the option on, log into your WHM, click on Exim Configuration Manager, then click on Advanced Editor. Scroll down until you see “Add additional configuration setting” (It should be right above the section labeled “Section: BeginACL”). Select the option “disable_ipv6” from the drop down list, and set the value to “true” (without the quotation marks)
Click on Save at the bottom of the page, and you’re done.
If you want to leave it enabled, then you need to add the IPv6 address to your SPF record. Adding the following to your existing record, includes the IPv6 address
+ip6:fdcf:0851:5144:bff3:xxxx:xxxx:xxxx:xxx
In a full SPF record, it’ll look something like this.
yourdomain.com. TXT “spf1 +a +mx +ip4:192.168.1.1 +ip6:fdcf:0851:5144:bff3:xxxx:xxxx:xxxx:xxxx ~all”
Replacing the ip4 and ip6 with your own IP addresses
The post Gmail flagging all of your mail as spam first appeared on Server Sitters.
]]>The post How to correct 554 5.7.1 : Relay access denied email errors, and prevent them in the future first appeared on Server Sitters.
]]>When you send an email, your email client sends the email to your own mail server. Your mail server then sends it on (Relays) to the recipients email server. Their email server then delivers it to the recipient.
If you do not successfully authenticate to your own outgoing mail server before sending the email, then your server will deny the email from being relayed on to the recipients server. This is done to keep a spammer from being able to send mail using your server without proper credentials.
If you do authenticate properly, you can still end up with this error however. The recipients server can deny the relay, if their spam filters have detected the email as spam, or as coming from a spam source (IE: your server is on a blacklist). If this happens, then their server rejects the email, and you will again get a relay access denied error.
The first thing you should do is verify your email settings with your email provider. Make sure you have the proper Mail server, Username, and Password. Also, check whether or not you need to use SMTP Authentication, or if you need to use POP before SMTP.
If you are using POP before SMTP, you can run into sporadic issues with mobile devices. This is caused by your data network changing due to poor coverage, or if you change from one WiFi hotspot to another. What is happening is your IP address may be changing, so you are now sending email from a new IP address instead of the IP address you originally authenticated with. To prevent this, you can try switching to SMTP Authentication to test if your email provider has that enabled as well. If that fails, then you may need to contact your email provider and ask them to enable SMTP Authentication on the mail server.
Finally, there could be spam filters coming into play on the recipients server. If this is the case, you should have your email provider look through the mail servers log files to get more information on how to prevent this.
There are 2 reasons a server owner may come across this.
You should see something like this in your log files.
2016-10-10 14:05:23 1btaGg-0004ei-Mf ** email@address.com R=dkim_lookuphost T=dkim_remote_smtp H=someserver.com [192.168.0.1] X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=yes: SMTP error from remote mail server after RCPT TO:<email@address.com>: 554 5.7.1 <email@addrss.com>: Recipient address rejected: Access denied
If ALL of your end users are getting this error, then this is the most likely case. You’ll need to check over the servers authentication configurations.
For example, if you were running a Postfix server, you should make sure that SMTP authentication is enabled. To do this, check the configuration file, and make sure that “smtpd_recipient_restrictions” is set like this
smtpd_recipient_restrictions = permit_sasl_authenticated
Occasionally, when server software is updated, it can change configurations. So if your server has been running fine all along, then all of a sudden it stops, then likely the software has been updated recently. For instance, cPanel automatically checks for updates nightly. There have been times where they rolled out an update that has broken things, and either a new update is put out, or you need to manually change some settings.
If you are updating manually, you should look into having a test server setup that you can test your updates on first. Then if everything seems to run fine on your test server, you can roll it out to your live environment.
On servers like Odin Plesk, they store the username, password, and authenticated IP address in a database. That database, like any database could become corrupt for any number of reasons. You can repair the table with a simple command line.
mysqlcheck -r psa smtp_poplocks -uadmin -pThis will check the table called smtp_poplocks and repair it if it’s broken.
If your are receiving reports that someone is trying to email one of your end users, but the person sending the email is getting rejected by your servers spam filters, then you may see entries like this in your mail log
2016-10-10 14:05:23 H=(myserver.com) [xx.xx.xx.xx] sender verify fail for <myuser@mydomain.com>: response to "RCPT TO:<myuser@mydomain.com>" from senderserver.com [yy.yy.yy.yy] was: 554 <myuser@mydomain.com>: Relay access denied 2016-10-10 14:05:23 H=(myserver.com) [xx.xx.xx.xx] F=<myuser@mydomain.com> rejected RCPT <senderuser@senderdomain.com>: Sender verify failed
This error indicates that myserver.com rejected an email from senderserver.com because of a spam rule called Sender Verify (Sender Verification Callout)
To correct this, here are 3 possible solutions
Anti-spam checks are something every server should have enabled, however being too aggressive can cause your clients to miss important emails. This is why it’s best to stick to the RFC compliant spam checks, as these are what a majority of service providers are configured with.
If your end users are getting bounced email with an error message like this:
Then your server is likely failing the recipients server anti-spam rules or on their firewall blacklists.
If this is the case, then view the headers of the bounce email. It should give your details as to why it was rejected. Typically, it’s caused by your server ending up on RBL’s (Realtime Blackhole List). There are a couple of sites that you can check your server against many blacklists, such as http://mxtoolbox.com and http://multirbl.valli.org. These lists will tell you any blacklists that you may be one, and will often give links to those RBLS, so you can request delisting. Before you ever try to delist a server however, you should make sure that the cause of the blacklisting has been resolved. IE: if you have a spammer on your server, they have been removed.
Probably 80% of our calls and support tickets regarding email issues in general, not just relay denied errors, are caused by the customer having incorrect settings. If you are certain that your server is working fine, then you should go over the settings with your client to ensure they have everything configured correctly to work with your server.
The post How to correct 554 5.7.1 : Relay access denied email errors, and prevent them in the future first appeared on Server Sitters.
]]>The post Track what folders are sending out the most email on a cPanel server first appeared on Server Sitters.
]]>
grep cwd /var/log/exim_mainlog | grep -v /var/spool | awk -F"cwd=" '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -n
This will give you a list of all folders that contain a mail script that has recently been used to send out mail. it will count the number of times each one has sent an email, and it will sort them from least to most.
The post Track what folders are sending out the most email on a cPanel server first appeared on Server Sitters.
]]>The post Sending mail from command line on Linux first appeared on Server Sitters.
]]>
This one uses PHP to send the email. Simply replace test@somedomain.test with your own email address.
php -r “mail(‘test@somedomain.test’, ‘test’, ‘test’);”
To send mail directly to the mail queue without the use of PHP, use the following.
mail -v test@somedomain.test
It will then ask you to supply a subject. Just type in test and press enter. It will then take you to a blank line. You can either put a message, then on a blank line put a single period “.” to send the email, or if you don’t need to put a message, just put a period, and press enter.
The post Sending mail from command line on Linux first appeared on Server Sitters.
]]>The post Send an email alert if mail queue gets too large first appeared on Server Sitters.
]]>There are many ways you can monitor this. Bellow is just one way to do this.
#!/bin/bash
############################################
# Script created by http://ServerSitters.com
#
# This will check the mail queue, and if larger then $qLimit, it will
# send an email to the address of your choosing letting them know
# how large the mail queue is
#
############################################
################### Configuration ###################
hostname="$(/bin/hostname)";
qSize="$(/usr/sbin/exim -bpc)";
qLimit="700"; #if the queue is larger then this number, an email will be sent to the $sendTo email address
sendTo="you@youraddress.com"; # Separate multiple email addresses with a comma.
sendFrom="root@"$hostname;
############## There should be no need to edit bellow this line ##############
if [ $qSize -gt $qLimit ]; then
echo -e "There are "$qSize "emails in the mail queue" | sed 's/^/To: '"$sendTo"'\nSubject: *ALERT* - Mail queue on '"$hostname"' exceeds limit\nFrom: '"$sendFrom"'\n\n/' | sendmail -t
fi
Typically I will setup a cron to run every 30 minutes, on the hour, and half past the hour.
The post Send an email alert if mail queue gets too large first appeared on Server Sitters.
]]>The post Using telnet to test mail servers first appeared on Server Sitters.
]]>
telnet mail.yourdomain.com 110
Connects to the pop3 server
user YourUsernameHere
This submits your username to the server
pass YourPasswordHere
This submits your password to the server
list
This will list the emails in the inbox, including their ID number, and size
retr
if you want to read an email from the list, type retr # where # is the number of the email you want read. For example, to read the 2nd messge in the list, retr 2
dele
This will delete an email. After you issue the dele command, you put a number. This is the number of the email you want to delete. So for example, to delete message 1, type dele 1
Once you have finished, you need to make sure you type quit, otherwise it does not save the changes you made.
telnet mail.yourdomain.com 143
This opens the session to the IMAP server.
a LOGIN YourUsername YourPassword
This sends the username and password to the system (the “a” is a required part of the command)
a LIST “” “*”
This shows a listing of all the IMAP folders the account has
a SELECT INBOX
This will select the INBOX folder. You can repalce INBOX with any folder you wish to use.
a fetch 1:* flags
This will list all the emails in the selected folder, and will also tell you the flags like “seen” or “NonJunk”.
a fetch 1 body[header]
This command lists the header information of message 1 in the selected folder.
a fetch 1 body[]
This will list the header AND the contents of message 1 in the selected folder.
a store 1 +flags deleted
This command will set message 1 to be deleted. (NOTE: it will not delete until the expunge command has been run)
a expunge
This will delete any emails that you flagged to be deleted with the previous command
a logout
Disconnect from the IMAP server
telnet mail.yourdomain.com 25
This opens up a connection to the SMTP server
HELO client.example.com
This should be your own hostname (the computer hostname you are connecting FROM)
MAIL from: <sender@example.com>
This is the email address you want to send the test email FROM
RCPT to: <recipient@example.com>
This is the email address you are sending your test email TO
DATA
Begins the data entry for the email headers
From: sender@example.com
To: recipient@example.com
Subject: Test message
After each of these lines press enter to start the next line. After the 3rd line, press enter twice so that it puts a blank line between the Subject, and the body of the email
This is a test message.
This is the body of the message. Type whatever message you want here
.
A period on a line all by itself indicates that is the end of the email. It will then try to send this email to the recipient from the sender email address using the data you provided in the headers above.
The post Using telnet to test mail servers first appeared on Server Sitters.
]]>The post Deciphering CSF blocked messages on a cPanel server first appeared on Server Sitters.
]]>If you see an entry like this in CSF:
csf.deny: 123.123.123.123 # lfd: (cpanel) Failed cPanel login from 123.123.123.123 (US/United States/c-123-123-123-123.somedomain.net): 5 in the last 3600 secs – Wed Jun 11 15:55:47 2014
This could mean they failed to authenticate on cPanel, WHM, or Webmail. To check which it was, run the following command:
grep 123.123.123.123 /usr/local/cpanel/logs/login_log
When you run this, you’ll get output that looks like this:
123.123.123.123 – someemail@address.com [08/28/2013:12:56:02 -0000] “GET /cpsess8206284687/horde/index.php HTTP/1.1” DEFERRED LOGIN webmaild: security token incorrect
123.123.123.123 – someuser [01/14/2015:21:07:22 -0000] “POST /login/?login_only=1 HTTP/1.1” FAILED LOGIN cpaneld: invalid cpanel user someuser (loadcpdata failed)
123.123.123.123 – someuser [01/15/2015:03:54:34 -0000] “POST /login/?login_only=1 HTTP/1.1” FAILED LOGIN whostmgrd: user password incorrect
The first result mentions webmaild, so this means it was Webmail they tried to login to with the wrong password.
The second result specifically mentions cpanel, so this is cpanel they tried to login to with the wrong password
The third result says whostmgrd. whostmgrd is the only one that isn’t obvious. This is the WHM.
If you see errors like this:
123.123.123.123 # lfd: (pop3d) Failed POP3 login from 123.123.123.123 (DE/Germany/some-reverse-dns-info-here): 10 in the last 3600 secs – Tue Jan 13 10:15:36 2015
123.123.123.123 # lfd: (imapd) Failed IMAP login from 123.123.123.123 (US/United States/some-reverse-dns-info-here): 10 in the last 3600 secs – Tue Jan 13 21:31:16 2015
Run this command:
grep 123.123.123.123 /var/log/maillog | grep -i fail
Returns this
Jan 13 10:15:32 server1 pop3d: LOGIN FAILED, user=username, ip=[::ffff:123.123.123.123
OR:
Jan 13 07:04:00 server1 imapd-ssl: LOGIN FAILED, user=someusername@somedomain.com, ip=[::ffff:123.123.123.123]
The first one shows the client tried to login as just “username” to the pop3 server and it failed.
The second shows that they tried to login as “someusername@somddomain.com” to the IMAP server and it failed.
If you see this:
123.123.123.123 # lfd: (smtpauth) Failed SMTP AUTH login from 123.123.123.123 (US/United States/ some-reverse-dns.com): 5 in the last 3600 secs – Thu Jun 12 08:28:56 2014
Run this command:
grep 123.123.123.123 /var/log/exim_mainlog | grep set_id
You’ll see output like this:
2014-06-12 08:28:47 courier_plain authenticator failed for some-reverse-dns.com ([123.123.123.123]) [123.123.123.123]:4900: 535 Incorrect authentication data (set_id=someemail@address.com)
This shows that the user tried to authenticate to the SMTP server using the username someemail@address.com, but failed to authenticate
Now that you know what exactly the customer did wrong, you can let them know, so they do not keep doing it, and getting themselves re-blacklisted once you remove the block against their IP address.
The post Deciphering CSF blocked messages on a cPanel server first appeared on Server Sitters.
]]>The post Checking mail queues on OpenVZ cpanel containers first appeared on Server Sitters.
]]>
for i in $(vzlist | grep running | awk '{print $1}' ); do vzctl exec $i 'hostname; exim -bpc | grep -v "0"';done
This will execute exim -bpc on all the containers on the node, and return a result like this:
Server1.somedomain.com
2
Server2.somedomain.com
7
Server3.somedomain.com
3
Server4.somedomain.com
13465
So, in this case, server1 has 2 email in their mail queue, server4 has 13465 email in their queue. So it looks like server4 is likely sending out spam, and you need to act on this.
Setting up a cron to run a few times a day and then send the results to you via email would be useful in helping to keep spammers out of the VPS servers. It allows you to quickly eyeball which servers are likely to have spammers on them, and to help track trends.
A simple way to cron this would be like this:
In /root on the hardware node create a script. Call it check_mail_queues.sh
Set the permissions to 755 (rwxr-xr-x) (chmod 755 /root/check_mail_queues.sh)
In this file, but the following 4 lines:
#!/bin/bash
cd /root
for i in $(/usr/sbin/vzlist |grep running| awk '{print $1}'); do /usr/sbin/vzctl exec $i 'hostname; exim -bpc';done > /root/mail_queue_report
mail -s 'Mail Queue report' you@youremailaddress.com < /root/mail_queue_report
Then setup a cron like this:
0 * * * * /root/check_queues.sh
This will run the script every hour, and send an email to you@youremailaddress.com with the results.
This is confirmed working on both SolusVM and HyperVM. Both were running OpenVZ on them.
The post Checking mail queues on OpenVZ cpanel containers first appeared on Server Sitters.
]]>The post Cpanel Exim How To Clear The Mail Queue first appeared on Server Sitters.
]]>/etc/init.d/exim stop;
sleep 10;
killall -9 exim eximd
sleep 5;
#clean out the mail queue
find /var/spool/exim -mindepth 2 -type f -exec rm -rf {} \;
#clean out the mail db files
find /var/spool/exim/db -type f -exec rm -rf {} \;
#reset the eximstats database tables
echo “truncate table sends;” | mysql eximstats
echo “truncate table defers;” | mysql eximstats
echo “truncate table failures;” | mysql eximstats
echo “truncate table smtp;” | mysql eximstats
/etc/init.d/exim restart
The post Cpanel Exim How To Clear The Mail Queue first appeared on Server Sitters.
]]>