procmail
[Top] [All Lists]

Re: Folder problem

2004-01-08 12:35:58
At 10:55 2004-01-08 +1300, Adam Bogacki wrote:
Greetings, procmail-users !

Greetings.  In future mails, mind _not_ including smileys from web boards?

I'm new to this list , having had trouble subscribing via text mode. A web site someone suggested finally worked.

Uhm I'm guessing you mean subscribing via an emailed listserve command versus using the mailman web interface at lists.rwth-aachen.de. What you wrote makes it look markedly like you could't subscribe via email, and instead, are using a webmailer to post to the list (it would be truely disturbing to find that this is the case).

I have not been able to get procmail automatically putting mail into designated folders

Examples of the procmail config you are currently using would be sensible.

Trying to configure SA

Please do keep in mind that this is a procmail list, not an SA support group - we'll help you sort your procmail invocation and useage issues, but SA matters should be discussed on an appropriate SA list.

I have summarised the last two messages in the thread below. I'd be grateful for any constructive comments. I have the feeling I'm missing something obvious (eg. confusing '$MAILDIR/procmaillog' with './home/adam/Mail/procmaillog').

Well, JFTR, "./home/adam/"... isn't a sensible path declaration - ./ identifies the CWD, but /home/adam/ certainly has the appearance of being a common root-relative system path.

I have looked at my procmaillog again and, as far as I can make out, procmail was processing mail folder recipes until July 28th. The next date mentioned in sequence was September 29, from which time there is no record of it processing them. It might be relevant that during that time I changed from
Mail to $MAILDIR mode and may have changed something inappropriately.

Probably, since procmail doesn't have any support for "I'm arbitrarily taking the summer off". If you run into a sudden cessation of function, you should review what has CHANGED.

I have attached my environmental variables

Your .procmailrc isn't "environment variables".  It's your .procmailrc file.

FTR, posting what appears to be fragments of other replies to your message makes it difficult to follow your problem.

Fair comment, but I don't understand why my efforts to subscribe to it keep failing. <procmail-users(_at_)procmail(_dot_)org> does not seem to be (yet) up,

It used to relay messages to the list processor address at rwth-aachen.de, but hasn't done so for the past year (or two?). Not so long ago, I tried unsuccessfully to get SRB and Phillip to make appropriate changes to the procmail mail server and website respectively to reflect the actual way of things.

VERBOSE=yes
#MAILDIR=$HOME/Mail


SENDMAIL=/usr/sbin/sendmail
DEFAULT=$MAILDIR/INBOX
LOGFILE=$MAILDIR/procmaillog

With VERBOSE and LOGFILE set, *EVERY* message being passed to procmail should result in stuff being logged to your logfile. If you have messages arriving in your inbox and there's no record of it in the procmaillog, you need to check file permissions, and whether procmail is being invoked or not.

LOGABSTRACT=all
DROPPRIVS=yes

Unless you're running in a /etc/procmailrc file, DROPPRIVS is pretty much useless - procmail isn't running as ROOT on your behalf.

#Nukes duplicate messages
:0 Wh: msgid.lock
| $FORMAIL -D 8192 .msgid.cache

Spiffy. read 'man procmailex' - note that if there are delivery problems after the dupe has been checked for, when the message is requeued, it'll be considered a dupe. For this reason, you might consider using the revised recipe which appears AFTER the warning.

I'm not sure what you are referring to here. None of the examples I used to set up muttrc and procmailrc had a '.forward' entry.

Well, do you HAVE a ~/.forward file?

% I have attached my environmental variables below for comment.
% They are followed in procmail by SpamAssassin stuff, then recipes.


OK.  How do you think you're getting mail to procmail?  Are you sure you
are?

Ask yourself: do you KNOW that your ISP hasn't been changing their MTA configuration, say toggling between having procmail configured to be LDA, and then NOT having it configured?

If your ISP is managed by some nitwit who is changing the MTA configuration in this manner and not first checking to see if there are any .procmailrc files in the system (which means there are users making use of procmail-as-LDA), you might start looking for a new ISP. At a bare minimum, if such config changes were made, the ISP should have sent notifications out to its users saying they were effecting the changes.

>From MAILER-DAEMON Fri Nov 28 14:48:32 2003
 Subject: Warning: message 1AP6jl-0000WS-1V delayed 24 hours
  Folder: /usr/bin/formail -D 8192 .msgid.cache

As your quote of previous discussions from other lists lacks a date reference, I have no idea if you wrote this two days ago, or circa 28 NOV. Certainly though, it seems that at least the message which was filtered at that time was successfully processed by procmail. Perhaps log info from a _regular_ message, rather than a DSN (and one that was tagged as a duplicate at that), would be appropriate?

OR, are ALL of your log entries like the above - showing DSNs being shuttled to trash? If so, my suggestion would be to immediatley comment out that messageid cache filter and review the messages which are being discarded.

Tux:/# find -name procmaillog -print
./home/adam/Mail/procmaillog
./home/adam/.themes/adam/Mail/procmaillog
./home/adam/.themes/.themes/adam/Mail/procmaillog
./home/adam/.themes/.themes/.themes/adam/Mail/procmaillog

Uhm, what's up with the .themes/.themes/.themes cruft? Looks rather like the results of a hokey backup script.


You might hit the link in my .sig and download (AND READ!) the procdiag shell script. After reading the script, execute it and review the output. You might have tripped on some file permissions (group or world writeable on your .procmailrc file for instance).

Also, inquire with your sysadm what the LDA is configured as -- if it isn't procmail, then you NEED a .forward file in order to invoke procmail (and only if procmail isn't the LDA - it's redundant to have it configured as the LDA and then invoke it from a .forward). If procmail isn't invoked, your mail will simply be deposited into your user mailbox.

---
 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

<Prev in Thread] Current Thread [Next in Thread>
  • Folder problem, Adam Bogacki
    • Re: Folder problem, Professional Software Engineering <=