Well..... I would dare say that a large (if not most) of the users of a program like this would have access to the mail server. A dedicated server often runs the mail program (it has on each of the servers I've run for the past 6-7 years).
If it can be done at the qmail level, that would be an option -- even if it's the only one that is truly viable. There is a 'double bounce' setting of some sort,and other things that can be looked at.
Also, what information does the mailer have that the script wouldn't, when parsing the headers?
If a "human" can sit and see the headers, and pick out the fields, a program can do it much better.
For instance...
The mail bounces once. We know it does, because it's in the bounced mail folder.
Now, we know it most likely bounced because one of the delivery addresses (usually the to:) was bad.
If the to: and from: are different, an attempt to deliver the message to the from: address and let them know the mail bounced would be good.
Additionally, if this was a "mailing list" the to: field needs to be removed from the mailing list, and put on a 'suspect' list, so it's not mailed to again.
Perhaps keeping a list of recent bounces, so that you don't enter a ping pong game would make sense, but if the headers can be properly parsed that would just be a security thing from a malicious hacker who would find a way to do it anyway. Limit the number of "bounced replies" to any server or address to a certain number per unit time, depending on how busy your mailer is. Bounces from a mailing list are much more time-compressed than routine member mailings, the program should "wait" before acting on any mailing list bounces.
There just _has_ to be a way to keep a pretty up to date list of addresses, and to handle bounces so that senders are properly notified.
If it can be done manually, it can be done with PERL <G>
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ
If it can be done at the qmail level, that would be an option -- even if it's the only one that is truly viable. There is a 'double bounce' setting of some sort,and other things that can be looked at.
Also, what information does the mailer have that the script wouldn't, when parsing the headers?
If a "human" can sit and see the headers, and pick out the fields, a program can do it much better.
For instance...
The mail bounces once. We know it does, because it's in the bounced mail folder.
Now, we know it most likely bounced because one of the delivery addresses (usually the to:) was bad.
If the to: and from: are different, an attempt to deliver the message to the from: address and let them know the mail bounced would be good.
Additionally, if this was a "mailing list" the to: field needs to be removed from the mailing list, and put on a 'suspect' list, so it's not mailed to again.
Perhaps keeping a list of recent bounces, so that you don't enter a ping pong game would make sense, but if the headers can be properly parsed that would just be a security thing from a malicious hacker who would find a way to do it anyway. Limit the number of "bounced replies" to any server or address to a certain number per unit time, depending on how busy your mailer is. Bounces from a mailing list are much more time-compressed than routine member mailings, the program should "wait" before acting on any mailing list bounces.
There just _has_ to be a way to keep a pretty up to date list of addresses, and to handle bounces so that senders are properly notified.
If it can be done manually, it can be done with PERL <G>
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ
