At 05:24 2004-02-10 +0000, axid3j1al axid3j1al wrote:
So Sean B. Straw,
Is there any way to do the aforementioned filter with procmail system hacking
It isn't PROCMAIL you hack - it's your MTA. Follow my .sig to see an
example SMTP hack - but be forewarned, it hasn't been touched in several
releases of sendmail, and I _DO_NOT_USE_THE_HACK_ (I've got no need to, nor
do I desire the additional mail processing load) -- I wrote it to provide
an example, which worked with sendmail at the time it was written.
I would strongly suggest that if you're going to try MTA hacks, that you do
so on a test host - a box you set up for the purpose of thrashing.
and a relevant rule for OUTGOING mail or is there an alternative way?
Once you have an MTA hack in place, it should be invoking procmail with a
specific rcfile which you'd specify for outgoing emails only. Of course,
you desire to have a recipient-specific ID number inserted, which means the
recipe would need to track every recipient (how about CC and BCC?), somehow
managing to make separate copies for each recipient, since they'd need to
have separate ID tracking numbers (if you've sent 4 messages to tony
already, and none to betsy, addressing them BOTH should necessitate an ID5
on tony and an ID1 on Betsy's copy).
Like, have fun. I don't think I'd prod that one even if someone were
waving money at me. Actually, I think that'd make me even MORE leery of
trying to "solve" it because they'd hold me responsible to work out the
kinks for every problem they run into, and there's going to be quite a
few. A sendmail "MILTER" might be feasable, but that's not what this list
is about.
You'd more easily grep your server MAILLOG and take the MESSAGEIDS and
place them (and the recipients) into an SQL database accessible from a
webpage someplace. Don't forget to store the receiving server and the
result code (in case you grab FAILED deliveries in the grep operation -
which is yet another problem with trying to do this in Procmail).
Is the "system hacking" way intractable? If not I would like to see a
framework to implement it.
So would all the idiots who think that adding a 20-line disclaimer to the
bottom of all messages sent from their mail server saying that the messages
may be confidential in nature, are intended for their intended recipient,
and should be returned if misaddressed, etc., actually provide any
protections to their correspondance. People working in law offices mostly,
who should know better than to think placing a disclaimer at the *END* of a
correspondance would have any weight.
IOW, it's been pushed for in the past, but that doesn't make it any more
feasable now even if your particular need has some legitimacy.
I doubt the whole thing is worth the effort though: it's a given that many
sites filter mail, and when they THINK it is spam, bouncing it is a bad
idea, and notifying the intended recipient doesn't generally happen - so
your server can show loads of mail being delivered to a user's mailhost
that the user may never see if their mail is subject to filtering at their end.
---
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