<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: 451 Could not complete sender verify callout</title>
	<atom:link href="http://rackerhacker.com/2007/03/29/451-could-not-complete-sender-verify-callout/feed/" rel="self" type="application/rss+xml" />
	<link>http://rackerhacker.com/2007/03/29/451-could-not-complete-sender-verify-callout/</link>
	<description>Words of wisdom from a server administrator</description>
	<lastBuildDate>Wed, 16 May 2012 12:56:36 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: dmmcintyre3</title>
		<link>http://rackerhacker.com/2007/03/29/451-could-not-complete-sender-verify-callout/#comment-23505</link>
		<dc:creator>dmmcintyre3</dc:creator>
		<pubDate>Tue, 19 Jul 2011 12:07:34 +0000</pubDate>
		<guid isPermaLink="false">http://rackerhacker.com/2007/03/29/451-could-not-complete-sender-verify-callout/#comment-23505</guid>
		<description>Another problem that is missing is if the sending mail server is not set up to receive emails to the domain in the from address. I send mail from my own mail server but let Google Apps handle the incoming mail, so anybody who&#039;s mail server has this enabled can&#039;t receive mail from me.</description>
		<content:encoded><![CDATA[<p>Another problem that is missing is if the sending mail server is not set up to receive emails to the domain in the from address. I send mail from my own mail server but let Google Apps handle the incoming mail, so anybody who's mail server has this enabled can't receive mail from me.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: EastGhostCom</title>
		<link>http://rackerhacker.com/2007/03/29/451-could-not-complete-sender-verify-callout/#comment-22585</link>
		<dc:creator>EastGhostCom</dc:creator>
		<pubDate>Sat, 02 Apr 2011 17:23:11 +0000</pubDate>
		<guid isPermaLink="false">http://rackerhacker.com/2007/03/29/451-could-not-complete-sender-verify-callout/#comment-22585</guid>
		<description>This is what&#039;s going on in our case


I sent an email from mike@my.dom to my_distro_list@myother.dom

One of the recipients on the my_distro_list has a server which apparently performs this &quot;sender verify callout&quot; which is another name for a callback, that is a reverse check to make sure the sending server -ALSO- accepts email for the original sender (i.e., mike@my.dom).

The &quot;fix&quot; was to make the outgoing server for myother.dom act as backup MX for my.dom

That way, when the recipient server gets the email I sent to my_distro_list, it can verify that the sending server for myother.dom also accepts email for my.dom

Presumably this check/verify helps thwart spammers, but not clear how -- if some stupid server acts as an open relay then it acts as an open relay and in so doing answers affirmative, that it does accept email for whatever initial sender domain(s).

So this whole business seems right now like a giant waste of time and it probably is, as others have asserted, a mechanism for DoS, as someone could basically make a server performing these silly &quot;sender verify callouts&quot; do extraneous work along with whatever unwitting target server(s) respond to those callouts.</description>
		<content:encoded><![CDATA[<p>This is what's going on in our case</p>
<p>I sent an email from <a href="mailto:mike@my.dom">mike@my.dom</a> to <a href="mailto:my_distro_list@myother.dom">my_distro_list@myother.dom</a></p>
<p>One of the recipients on the my_distro_list has a server which apparently performs this "sender verify callout" which is another name for a callback, that is a reverse check to make sure the sending server -ALSO- accepts email for the original sender (i.e., <a href="mailto:mike@my.dom">mike@my.dom</a>).</p>
<p>The "fix" was to make the outgoing server for myother.dom act as backup MX for my.dom</p>
<p>That way, when the recipient server gets the email I sent to my_distro_list, it can verify that the sending server for myother.dom also accepts email for my.dom</p>
<p>Presumably this check/verify helps thwart spammers, but not clear how -- if some stupid server acts as an open relay then it acts as an open relay and in so doing answers affirmative, that it does accept email for whatever initial sender domain(s).</p>
<p>So this whole business seems right now like a giant waste of time and it probably is, as others have asserted, a mechanism for DoS, as someone could basically make a server performing these silly "sender verify callouts" do extraneous work along with whatever unwitting target server(s) respond to those callouts.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sanchon</title>
		<link>http://rackerhacker.com/2007/03/29/451-could-not-complete-sender-verify-callout/#comment-16290</link>
		<dc:creator>sanchon</dc:creator>
		<pubDate>Thu, 27 May 2010 10:32:28 +0000</pubDate>
		<guid isPermaLink="false">http://rackerhacker.com/2007/03/29/451-could-not-complete-sender-verify-callout/#comment-16290</guid>
		<description>The most obvoius problem is missing:
If the sender is using sender callout verify himself, the verify will never succeed as the verification targat wants a verification from the verifier first.
Besides it can be used conveniently for DOS attacks.
This is why sender callout verification should NEVER be enabled (and not even offered by EXIM)!</description>
		<content:encoded><![CDATA[<p>The most obvoius problem is missing:<br />
If the sender is using sender callout verify himself, the verify will never succeed as the verification targat wants a verification from the verifier first.<br />
Besides it can be used conveniently for DOS attacks.<br />
This is why sender callout verification should NEVER be enabled (and not even offered by EXIM)!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

