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: [email protected] [mailto:[email protected]] On
Behalf Of Sven Hartge
Sent: Monday, May 09, 2011 11:31 AM
To: [email protected]
Subject: Re: [exim] Virtual Forward To's Eliminate NDR's
John Traweek <[email protected]> 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 [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.
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: <[email protected]> -> <[email protected]>
Now <[email protected]> is no longer valid, but <[email protected]>
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/
--
## 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/
