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 user1@??? forward to user2@???.
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 user2@???.
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 virtualuser@??? forwarding to
user@???. 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.
