Thanks for all of the replies. I have a lot to think about now :)
I think I am going to roll with something along the lines of what Bill and Sven are suggesting. Although SRS is probably the long term solution, this is not my number one priority and we haven't had any complaints that I know of in regards to ISPs completely dropping forwarded mail. We do get some that move the forwarded mail to SPAM folders, but this has always been rectified by adding the email address to a "safe" list or address book.
As Bill suggests, since I am using a "flexible" DB, I was simply thinking about having a flag in the DB that will toggle forward to's as valid or invalid. I can simply modify my virtual_userforward
EXISTING -
SELECT forward FROM fw WHERE domain='${quote_mysql:${domain}}' and username = '${quote_mysql:${local_part}}'
REVISED -
SELECT forward FROM fw WHERE Valid = 'Y' and domain='${quote_mysql:${domain}}' and username = '${quote_mysql:${local_part}}'
That way we can just nip it in the bud right at the RCPT_TO
However, in regards to updating the Valid flag when an address is deemed invalid or has been on a 4XX for a long period of time I am a little foggy...
I assume that I will receive two types of notifications for bad forward to's.
1. During the SMTP transaction with the destination server.
2. Receive an NDR from the destination server at some point post transaction
How would I go about parsing these out? I assume I could simply parse the logs using a scheduled job or can Exim do some of this for me? I guess I would like this data to go into a table within MYSQL, so I can write a SQL job to simply go out and do some calculations based on frequency etc to trip the valid flag to N. I am quite good at SQL, but Exim and Linux are new to me, so any input would be appreciated. Thanks.
________________________________
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.
-----Original Message-----
From: exim-users-bounces@??? [
mailto:exim-users-bounces@exim.org] On Behalf Of Sven Hartge
Sent: Monday, May 09, 2011 11:31 AM
To: exim-users@???
Subject: Re: [exim] Virtual Forward To's Eliminate NDR's
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.
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
--
## 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/
