John Traweek <johnt@???> wrote:
> 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.
Hmm. Is there a specific reason to use such an old LTS? Why not the
newer 10.04 version?
> 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?
It is possible (called recipient callout), but I strongly advise against
this practice.
I know for a fact that several big mail providers (like Yahoo and
Hotmail) will blacklist your whole service rather quickly if you use a
recipient callout verify check.
Assume the following scenario: <user1@???> -> <user@???>
Now <user@???> is no longer valid, but <user1@???>
still gets mail. Everytime a mail is received, your system will trigger
a callout to the now non-existing mail-address and after enough failed
delivery attempts (which are no real delivery attempts, but the target
service cannot know this) Yahoo will blacklist _all_ delivery attempts
from your system (for 24 hours), even for working target mail addresses.
Other providers like AOL and Hotmail behave the same or similar way.
One solution might be to parse the log files of your outbound servers
every day and disable all mail addresses which have failed in the last
24 hours.
This will of course not prevent the generation of late bounces, but it
will quickly shut of the offending forwarding addresses.
