note
Limbic~Region
[merlyn],
<br />
Unfortunately I am no longer with the U.S. Dept. of Justice to give specific examples, but the list of all the internet MTAs you mentioned was in my experience quite limited. The gateway delt with many hundreds of thousands of emails a day. The <del>gambit</del> gamut of mail systems that they communicated with was quite large to include, but certainly not limited to, CC:Mail, (old) GroupWise, and your beloved Microsoft Exchange. Additionally, there are other prehistoric mail systems out there, home grown ones, etc that I assure you are not RFC compliant.
<p>
When the problem was with a modern system, it was almost always do to administrative modification to prevent anti-impersonation and open-relay. Since I can't give specific examples of MTAs that do not accept RFC compliant email addresses, [http://www.rfc-ignorant.org/] is a site dedicated to listing domains that don't think the rules of the internet apply to them (postmaster, DSN, etc).
</p>
<p>
Finally, it is arguable that I am using MTA (Message Transfer Agent) too liberally. For instance in the case of CC:Mail and GroupWise, the internal mail system was not native SMTP and so the gateway/MTA had to additionally translate the incoming address to the native format. Or perhaps if the MTA is only accepting mail for a specific domain which happens to be a specific mail system - than it is not a true MTA. I will not argue except to say my original point was referring to specific situations. Admittedly, I should have been clear:
<ul>
<li> You are only validating "to" addresses for "incoming" emails </li>
<li> You are validating requests for new email accounts on your specific mail system </li>
</ul>
</p>
Now that the [393841|context] is known, the possibilities I presented are pointless.
<div class="pmsig"><div class="pmsig-180961">
<p>
Cheers - [Limbic~Region|L~R]
</p>
</div></div>
<b>Update:</b> Word correction thanks to [Albannach]
393804
393843