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.

1. Turn the above option ON, which turns off IPv6 in Exim
2. Add your IPv6 address to your SPF record

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 sender did not authenticate to the outgoing mail server
• The recipients server has determined the senders server to be a source of spam, or that it had failed security checks

What exactly is a relay access denied error?

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.

What to do when you get this error as a user.

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.

What to do when you are the owner of the mail server

There are 2 reasons a server owner may come across this.

• An end user tried to send an email, and they are sent this error in a bounce back
• A person trying to send an email to a user on your server is getting the error, and they have reported it to you

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

The user authentication system could be failing

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.

The authentication database could be corrupt

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 -p

This will check the table called smtp_poplocks and repair it if it’s broken.

3rd party mail coming to your server is failing anti-spam checks on your server

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

1. If this happens often to legitimate email, and is caused by the same anti-spam rule, then you may want to consider disabling that particular rule.
2. If the server sending the email is trustworthy, you can add their server to your servers whitelist.  Use caution with this however, as this will allow all mail from their server through without any spam checks at all.  So if their server is ever hacked, and used to send out spam to your server, all that spam will get through.
3. Contact the sending server, and request that they re-configure their server to make the server compliant to your anti-spam checks.

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.

Your users are getting bounce backs due to anti-spam rules on the recipients server

If your end users are getting bounced email with an error message like this:

• 454 4.7.1 : Relay access denied

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.

The End user’s mail client is configured incorrectly.

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.

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.

There was a bug in SpamAssassin that hit Jan 1st, 2010. All emails were getting marked with the above error in SpamAssassin, and it was adding 3.5 to the spam score, thus getting blocked by most standard spamassassin configs.

To fix this, simply run sa-update from a linux command line.

The post Spam Assasin 2010 Bug first appeared on Server Sitters.

Here’s an example:
Client has the domain: yourdomain.com
Client has setup test@yourdomain.com to forward to test@aol.com

A spammer sends a message to test@yourdomain.com. The message is received by the client’s server. It is then forwarded to test@aol.com. The client then logs in to aol and they view the message. The message is nothing more than spam and they then click “Mark as Spam” or “Report Spam”.

Now since the last server to receive the message was their own domain, they’re telling AOL that they’re own domain just sent them spam. Eventually this will lead to AOL and other RBL’s blocking their server! The Internet is mature, but not mature enough for it to follow the forwarding path to notice that the client is trying to report the sender as a spammer and not their own server. When this occurs we usually send the client the following:

Important AOL email forwarding issue –
We’ve been contacted by AOL because your account has been reported for spamming. We worked with them to resolve the issue.

To ensure this doesn’t happen again you should not use the Report as Spam button when checking your email through AOL. You’re actually reporting yourself for spamming.

Here’s Why:
You have your email account with us configured to forward to your aol email address. When a spammer sends you an email message it’s received by our server. Then your email account forwards it to AOL from our server. You receive it at AOL and report it as spam. Aol’s system isn’t smart enough to realize that you’re reporting the spammer from a forwarded message. Instead since the message last went through your account on our server prior to being forwarded to AOL they think you’re reporting your own email address on our system as a source of spam.

Please discontinue reporting spam via AOL or we’ll be forced to remove the AOL forwarder on your account to ensure we don’t get in trouble for the spam complaints.

The post AOL Blacklist first appeared on Server Sitters.