We allow our customers to set up vanity email addresses, which we market as email for life accounts. The accounts are strictly forwarding accounts, so there is not a "mailbox" so to speak. Mail comes in, and is forwarded on to a permanent account. So for example, a customer may wish to have an account [email protected] forward to [email protected]. If two years from now, the customer changes ISP's from AOL to a Yahoo account, he or she would simply access our system and change the forward to [email protected].
We have had this product in place for about ten years using a multitude of systems, including Barracuda gateways, a group of load balanced servers to perform the forwarding mechanism and another group of servers to perform the outbound delivery. I am looking at moving everything to a couple of servers running Exim4, SpamAssassin, ClamAV, and MySQL using virtual users. I am an exim newbie and Linux newbie, but have managed to get a test box set up on Ubuntu 8.04 LTS and everything seems to be running great. One of the problems we have with our old setup is that people will let their forward to address go bad and never update it. So when the message finally gets to the outbound MTA's destined to one of these bad forward to's an NDR is generated and sent back to the sender. Not so good... It's a perfect back spattering spam machine. One of the nice things I have noticed about Exim is that out of the box with the way I have it set up it will verify the forward to domain. So for example, I have [email protected] forwarding to [email protected]. During the initial receiving transaction Exim will verify baddomain.com. If it doesn't exist it will 550 the transaction and no NDR from my server. Great! So my question is can it also verify the RCPT TO of the forwarding address during the original transaction as well? This would issue a transaction response back to the connecting MTA, thus preventing further NDRs being generated? If this is possible, what will happen with non permanent failures, such as 400's, ie mail box full etc? Will those be issued back to the originator during the transaction, so the responsibility is put back on the originating MTA to retry the transmission? TIA ________________________________ John Traweek Executive Director, Information Technology Proud PCI Associate for 14 years PCI: the data company Heritage Square 4835 LBJ Freeway, Suite 1100 Dallas, TX 75244 214.530.0394 We drive engagement. We accelerate contributions. This Email is covered by the Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521 and is legally privileged. The information contained in this Email is intended only for . If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distributions or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us by telephone 1.800.395.4724 X160, and destroy the original message. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
