On Wed, 10 Dec 2003, Professional Software Engineering wrote:
At 23:58 2003-12-10 -0500, Charles Gregory wrote:
Well, I would think that the 'mechanism for control' would be the
exitcodes that are returned from procmail.
ANd if you return an exit code, that's all procmail can do - if your MTA
does something different, or emits an unusual message to the sender, that's
an MTA problem.
Unless the 'problem' *is* in PROCMAIL. Take a look at the log:
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:
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. This
WORKS for sucessful deliveries. But, it appears that somehow procmail is
acting on a 'fallback' scheme that says "If the procmailrc specified
default mailbox is undeliverable, try the system default".
And it does it for EXITCODE=77 (permission denied) among others.
So, anyone know how to quash this 'fallback' behaviour within procmail?
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.
But while we're here, I'd like to make a comment about the poor advice
received so far:
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*
of this, and considering it a possibility. As it happens, Postfix DOES
have a built-in LDA. 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. This
really does make sense, and that is why I posted to the procmail list and
not the postfix list. And this determination seems to be upheld by
testing.
BUT just before you start laughing, please consider that you looked at the
clear report that *something* was 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?
And just to save a round of e-mail, are you going to complain that I did
not state the problem clearly enough? Every day I deal with inexperienced
users who poorly express their problems, and I ask a few probing
questions, and get to the heart of the matter. In your case, it seems that
your 'expertise' does not include this basic skill. And if you are going
to ask "why should you bother?" then I have to ask why you could be
bothered to provide an inadequate, mis-directing response. Please,
for the sake of clear understanding, particularly for inexperienced
users, either DO bother to help, or don't bother at all.
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.
In any event, you could write yourself a little program which does
nothing more than return a specific exitcode and set your MTA to
deliver using that program, and you'd be able to see the same thing
happen, thereby reinforcing that it's an MTA problem.
Sorry, but I really didn't feel like being laughed at again, by taking my
mail service offline so stupidly. 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. When I encounter a user that is
*that* ignorant, I start to spell things out in great detail, knowing that
they clearly don't know what they are doing. You just seem to throw out
tidbits with the arrogant attitude that the other guy "should know what he
is doing". Well, maybe he should, and the way for that to happen is by
*learning* and *experience*. Neither of which comes from listening to
someone laugh at you.
- Charles
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail