On Wed, Oct 03, 2001 at 10:33:26AM -0400, Colin J. Raven wrote:
> Manually this would take forever, there has to be a better way using
> procmail.
I dunno, sounds like a great way to make this coworker learn that you don't
create a list and add people's addresses to it.
Whatever happened to opt-in anyway?
(please remember to post followups to list, not to me)
At 17:07 2001-10-03 -0700, Andrew Edelstein wrote:
Performance wise, You'd probably be better off putting that huge file in some
kind of database and deleting entries from that as they come in. But since I'm
by no means a database guru, I'll leave it for someone else to help with that
(that's beyond the scope of procmail anyway).
You can put addresses in a simple Berkeley DB and manipulate them with a
small C/++ or Perl program invoked by procmail, passing it an argument: the
extracted From: (or reply-to) address:
:0:
* ^TOunsubscribe(_at_)naughtyco\(_dot_)com
{
FROM=|formail -rt -xTo:
# i ignores write errors from your script not necessarily reading
# the message provided to it on stdin.
:0i
|/path_to_script/unsubscribe.pl $FROM /path_to_db/dbfile
}
Actually providing the dbfilename on the commandline to the script will
allow the one script file to be used for multiple such databases (your ^TO
expression could be "unsubscribe-doofi(_at_)naughtyco\(_dot_)com" or
"wtclist-unsubscribe(_at_)naughtyco\(_dot_)com", etc - each one with its own database
file).
Note that the rule is locked, so that we don't have multiple unsubscribes
concurrently accessing the file (though the external script should just use
file locking when updating the db - and really, whether procmail provides
locking on the rule, the script should endeavor to file lock its own
database anyway).
Handling an autoreply would be as simple as invoking formail just as you
regularly would for an autoreply, but having your script emit the body for
the message - appropriate to whether it matched the address in the database
or not:
:0
| (formail -rt -I "Subject: unsubscribe from naughtyco list" \
-I "From: unsubscribe-bot(_at_)naughtyco(_dot_)com" | \
/path_to_script/unsubscribe.pl $FROM /path_to_db/dbfile ) | \
$SENDMAIL -t
Insert this in place of the script invocation above. If your script reads
in STDIN and outputs it, then emits it's own message body (error or
success, and the processed address), then the user would get a report
back. The script could also emit a BCC: line at the top of it's own
output, if you wanted to recieve a copy of the errors...
I wrote up something similar, not for unsubs, but for a forced legal
acknowledgement that a series of lists needed to obtain from their members
- if the users didn't ack within a certain timeframe, the ack request would
be emailed out again (to those remaining unack'd in the db), and after a
couple of rounds of that, the remaining unack'd members would be removed
from the subscriber list for having not accepted the new list terms. In
part, to ensure that humans were responding, a codenumber unique to that
member (a hash basically) was how the subscriber address was looked up in
the db. Doing this also protected against users who were subscribed at one
address, but when they sent mail, might be coming from a different domain
(forwarded email), or different host (msn.com -> email.msn.com). A very
similar mechanism is used on some listservs to confirm new subscribers.
Andrew's solution should be more than adequate for what you're doing.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail