Re: Not sure why....

At 12:52 2003-12-11 -0500, Charles Gregory wrote:
> Unless the 'problem' *is* in PROCMAIL. Take a look at the log:
Ah, this would be the log you didn't share in your original post, or your 
second post for that matter?
Let me remind you that your original post shared NO procmairc code and no 
procmail logs.  You cited the conditions under which your MTA was returning 
a specific error.  Indeed, it'd be entirely my fault for taking you at your 
word that you actually knew that you were successfully setting EXITCODE and 
then terminating procmail.  Focus for a moment on "when I set EXITCODE=77".
You didn't cite under what conditions you set EXITCODE, but if you're 
successfully setting it (checking your procmail VERBOSE logs would be about 
the only sure-fire way to be able to state unequivocally that you had), 
then procmail hadn't up until that point terminated.  If you're not EXITING 
procmail (see 'man procmailrc' and search for EXITCODE -- note that simply 
setting it doesn't terminate procmail, it merely sets the code which 
procmail will return when it does terminate) but not actually terminating 
procmail until you've gone and attempted to do something else, then yea, 
procmail might emit something else to the log because it's continuing to 
attempt a delivery.
My bad for not compromising your system and examining the procmailrc you're 
using.  You're welcome to share your procmailrc so that the problem with it 
can be diagnosed.  Until then all anyone here can offer you are 
assumptions, conjecture, and WAGs.
> Dec 11 01:08:31 king postfix/local[20703]: 148A747C98:
> to=<aj569(_at_)king(_dot_)domain(_dot_)com>, relay=local, delay=1,
> status=bounced (can't create user output file.
> Command output: procmail: Couldn't create "/var/spool/mail/ai477" )
>                 ^^^^^^^^
>
> I further verified this by creating the "missing" directory, and then
> trying the mail again. Logs THIS time:
Hmm, this problem with "couldn't create ..." is inconsistent with your 
initial report of "disk quota exceeded"  Got any of those LOG entries?
It sure looks like you have multiple problems there.

> Dec 11 12:27:39 king postfix/local[8553]: 623EE47C98:
> to=<ai477(_at_)king(_dot_)domain(_dot_)com>, relay=local, delay=1,
> status=sent ("|/usr/bin/procmail")
>
> Keep in mind that the system default mailboxes are '/var/spool/mail/user'.
> I am setting 'DEFAULT=~/inbox' as the first line in procmailrc.
'man procmailrc', search for '~' (should be the second match).  If you want 
a users homedir, then use $HOME.
My fault for not spotting this, but since you reported that it _WORKS_ for 
delivery, I mistook the statement as a paraphrasing of what you're doing, 
rather than a direct quote from your procmailrc.
> This WORKS for sucessful deliveries.
Qute possibly the successful ones NOT involving delivery to the incorrectly 
defined $DEFAULT...
> And it does it for EXITCODE=77 (permission denied) among others.
> So, anyone know how to quash this 'fallback' behaviour within procmail?
Well, far be it for me to point this out, but procmail doesn't bail just 
when you set EXITCODE.  Try unsetting HOST to get procmail to bail on 
command, returning the EXITCODE you've set.
It's probably a big assumption on my part that you're actually terminating 
procmail in an appropriate fashion instead of setting EXITCODE and then 
letting procmail run its course in the rcfile, which certainly could appear 
to attempt default delivery (though, uhm, if to the $DEFAULT you've 
specified, there's going to be problems), and yet return an error to the MTA.
If you set procmail to log, and use VERBOSE logging, you'd be able to see 
the EXITCODE being set, and then watch procmail emit log items for the 
recipe conditions which followed it, which would provide this clue.
The proper use of EXITCODE isn't extensively documented in the manpages - 
you might find one of the FAQs to be a better resource for its use.
> By this point in time, I imagine that the lack of response on this issue
> means that no one has encountered this problem before, and so maybe I need
> to talk to the procmail developers.
Well, at this point, you're unlikely to heed my advice, but I'd first 
confirm that the procmailrc isn't buggy before going so far as asking the 
developers of the software to investigate something nobody else seems to be 
experiencing.
> > Don't make me laugh - the MTA handed the message to the LDA because it's
> > the LDA's job to deliver the message.  There is no fallback.
>
> You may feel free to laugh at me being ignorant enough to not be *certain*
You may need to chill.  Some would consider an MTA that elects to deliver a 
message by some method other than the one it is configured to, ignoring 
deliberate error codes returned by that process to be an error in the 
implementation of that MTA.  I certainly do.  How on earth could you bounce 
a message if the MTA insisted on delivering the message when the assigned 
program told it "there's a sytem resource problem" or somesuch?
Hey, I may very well be wrong - perhaps Postfix does have some fallback 
mechanism.  If it does, I extend my sincere condolences to those who run it.
> of this, and considering it a possibility. As it happens, Postfix DOES
> have a built-in LDA.
But, if you're telling it to use some other LDA, it'd be _WRONG_ of it to 
go ahead and use it's own when the specified LDA reports a delivery problem.
> I'll take your word for it that once that choice is made by postfix, it 
> will not 'fallback' to its own built-in LDA.
Well, please don't take my word for it - go check in a postfix forum.

> BUT just before you start laughing,
Actually, right about now, it's being transformed into an evil cackle.  If 
you end up confirming your rcfile has a error-by-omission, I might begin 
snickering, but rest assured, it won't degenerate into a snicker-snort, nor 
will it resemble a comedic laugh or guffaw.
> please consider that you looked at the clear report that *something* was
Would that be the clear report showing a procmailrc with a correlating 
verbose procmail log, as well as a block excerpt of the actual 
MTA-generated bounce?  Or are we talking about some other clear report here?
> attempting delivery to a "wrong" directory, AND that you "knew" that the 
> MTA could not perform local delivery as a 'fallback', and yet you told me 
> to go to the MTA discussion list to discuss a local delivery problem?
"the mail server reports a failure to open /var/spool/mail/username."

Note how the cited error message does not include any reference to a 
failure of the procmail program (unlike the maillog excerpts you just now 
provided)
> > Possibly postfix trying to provide fallback when it's not expected to.
>
> I'm sorry, let me quote from up above....
> > Don't make me laugh - the MTA handed the message to the LDA because it's
> > the LDA's job to deliver the message.  There is no fallback.
>
> Now I think it is MY turn to laugh. I'm not enough of an expert to tell
> you which of these two statements is true, but when you are making
> sarcastic comments that suggest your knowledge is far superior to everyone
> else's, you might not want to contradict yourself in the same e-mail.
My statement was intended to convey that it would be WRONG for the MTA to 
attempt a fallback - I mean, how does one reject a message if the MTA 
insists on doing something you didn't tell it to do?  Thus "when it's not 
expected to" -- your MTA might actually be configured to do something like 
this, but then, that'd be wrong.
> Sorry, but I really didn't feel like being laughed at again, by taking my
> mail service offline so stupidly.
If you're smart enough to know how to write such a routine and configure 
your MTA to utilize it, AND have root on the server, you aught to be smart 
enough to comprehend that such a mechanism would result in refused emails 
during the test.  I didn't spell out what should have been considered 
obvious (including making a backup of your original MTA config file).
You could accomplish a test via .forward on a test user account, possibly 
via an alias, or use a test host (as someone else is presently doing to 
test a script).  A clever admin who needs to run a test such as this might 
get a list of the port addresses that their MTA process is utilizing 
(rather than just trusting that it's only port 25) and temporarily firewall 
external traffic to that port, then make their test config tweak and 
restart the MTA, send a locally-originates test message, check the results, 
then undo the config change, restart the MTA, and remove the temporary 
firewall rules.  The MTA would be out of commission only for a few minutes, 
and the outside world would have delivered any new messages to your backup 
MX, which would have queued them for later delivery to your primary MX.
There are other techniques of course, but the above are pretty obvious 
ones, having varying degrees of test accurracy (the .forward will already 
have involved your configured LDA, and the alias used your program mailer, 
not the LDA, so if there's some funky LDA fallback in your MTA, it probably 
wouldn't experience it).  A separate test host is easy to utilize (in the 
biz, they're sometimes referred to as "staging" hosts), and always a good 
idea to have one around if you're a shop of any appreciable size.
> And again, I find it amazing that you offer such a simple but dangerous 
> piece of advice to someone who (in your sorry estimation) is worth laughing at.
Perhaps you can fish up a useful idea from the foregoing, or when you post 
your procmailrc and associated verbose procmail log excerpt, someone else 
will be happy to diagnose your troubles.  As for me, I think I'll go change 
my baby son's diapers - he's certainly more appreciative of the effort.
Santa is going to be crushed when he receives news that laughter is taboo.

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