Portal Home > Knowledgebase > Articles Database > Exim Sender Verify: yes or no?

Exim Sender Verify: yes or no?

Posted by diesel12, 10-30-2009, 05:57 PM
We had a non-client (not on our server) that was getting 550 email rejections when he attempted to email us due to having Sender Verify enabled. In the past I figured Sender Verify was necessary for fighting spam, amongst other things, but have realized that we may be having more rejections than we know because we never hear about them. Is there a general best practice in terms of enabling Sender Verify or leaving it off? I've never heard about complaints about rejects from legitimate emails senders, so it doesn't seem to be an issue, but then again, you really never know... hate to make a wrong assumption... any feedback appreciated.

Posted by samurai7, 10-31-2009, 02:28 AM
hi, Sender verification is new measure to try to stop and block email spam infection. You can go through the following steps on how to disable Sender Callouts Verification in cPanel/WHM 10.x #Login to the WebHost Manager. #On the Service Configuration section,click on Exim Configuration Editor link. #Uncheck and untick the checkbox next to Use callouts to verify the existence of email senders. option. #Press the Save button, and cPanel will auto restart Exim. Below is on how to disable Sender Callouts in cPanel/WHM v11 #Login to the WHM #On the Service Configuration section, click on Exim Configuration Editor link. #Uncheck and untick the checkbox next to ** Use callouts to verify the existence of email senders. Basiclly, exim will connect to the mail exchanger for a given address to make sure it exists before accepting mail from it. option. #Press the Save button at the bottom of the page, and cPanel will auto restart Exim.

Posted by part, 11-01-2009, 04:42 AM
Quick reply: No Leave it off since it is considered abuse to check the sender address. It is more often than not spoofed any way and that will cause problem for those that got their mail address spoofed on a lot of spam messages.

Posted by bear, 11-01-2009, 08:31 AM
Can't say I agree with that. We have it on, as there is no legitimate reason for a mail sender to be using an address that doesn't exist.

Posted by net, 11-01-2009, 08:39 AM
If you have a good anti-spam configuration, leave it off. Aside from adding load in the mail server, there are also some providers that use an email like noreply@ which doesn't exist and this will not reach your server if sender verification is enabled. So, if that email is important, you might lose the very important information.

Posted by woods01, 11-01-2009, 08:52 AM
This issue ties back to running a defensive network. Those that operate our internets do not want defensive networks. They want their networks to be able to hack, to spam, and to do whatever as long as they can say well we fixed it now or our network is too big for us to manage. So you'll end up on spam lists for running sender-verify but we utilize it and haven't noticed anything annoying. The only legitimate reason people talk down against it is because they do not support defensive networks. Just think how the world would be without caller-id in 2009, im sure those that are against sender-verify all have caller-id. Also if you look back on some of the rfc's you'll notice that you will find that some of todays 'anti-spam' and sites that are against running things such as sender-verify are breaking the rules for a smooth running internet. From what i've read and I could be wrong the utilization of blacklists in general were depreciated because of the negative impact it can have. Nobody wants spam and abuse but when you let organizations control policy that run off commercial interest; little guys find themselves forced to pay for email delivery. We have it already with governments assuring larger isps cannot have their ip space blacklisted on large scales. Last edited by woods01; 11-01-2009 at 08:59 AM.

Was this answer helpful?

Add to Favourites Add to Favourites    Print this Article Print this Article

Also Read
API Required (Views: 413)
donhost (Views: 401)