On Mon, Jan 14, 2002 at 08:40:39AM -0800, Professional Software Engineering
wrote:
At 15:59 2002-01-14 +0100, Manuel Hendel did say:
I've read an article in the Linux Magazine 01/2002. They describe a
way with formail:
####
:0 Wh: $PROCMAILDIR/msgid.lock
|formail -D 32768 $PROCMAILDIR/msgid.cache
/dev/null
####
but this didn't work for me for some reason.
Have you tried enabling VERBOSE logging and checking what the logfile says
about it?
Yes, I always do VERBOSE logging. But when comment in these three
lines, the logfile drives totaly crazy, and brings only messages about
msgid.lock and msgid.cache. It seems to be in a kind of loop.
Do you normally use procmail, or is this the first thing you've ever tried
(and if so, how do you know that procmail is even being run)?
Yes, I'm used to it.
Do the duplicates you speak of actually have identical messageids? Mailing
lists can pose problems when the list rewrites the messageid (some do), or
if the sending user's mail client and server don't properly add a
messageid, leaving the recipient server (initially the list server, but if
you get a cc, then your server as well) to generate a messageid - in these
cases, the messageid cache won't do you a whit of good as the messageids
will be different.
That's true, but the messageid seems to be the only way to check. If
there is another way would prefer it.
You should set up a sandbox testing environment (see some notes at the URL
in my sig) and run some tests outside of your live mailstream.
I will do this, thanks.
If the above recipe is verbatim from the magazine, you should write in and
tell them that they're purveying inaccurracies - the _delivery_ line is the
pipe to formail - the /dev/null isn't, and procmail is going to see that as
what _should_ be the flag line from another recipe, or as an assignment or
other operation (such as an INCLUDERC), but doesn't match the criteria for
those, and will emit:
procmail: Skipped "/dev/null"
to the logfile.
That's what I've seen as well. But what happens to the double mails,
if they won't get forwarded to /dev/null?
FTR, the very basis for the above filter has been presented in the manpage
'man procmailex' (procmail examples) for many years. The version that
appears there doesn't have the extraneous /dev/null line at the end.
What is $PROCMAILDIR defined to? Is it defined at all? If it isn't, then
you're trying to write your message cache to the ROOT of your filesystem.
$PROCMAILDIR = $HOME/.procmail
It's just a dir to store the procmail stuff.
Thanks in advance,
Manuel
--
...C++ offers even more flexible control over the visibility of member objects
and member functions. Specifically, members may be placed in the public,
private, or protected parts of a class. Members declared in the public parts
are visible to all clients; members declared in the private parts are fully
encapsulated; and members declared in the protected parts are visible only to
the class itself and its subclasses. C++ also supports the notion of
*friends*: cooperative classes that are permitted to see each other's private
parts.
-Grady Booch, "Object Oriented Design with Applications"
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail