At 10:04 2005-03-25 -0600, Mr Duck wrote:
Go ahead and keep the discard rule just after it (if the bounce
fails for some reason, that'll still discard the message)
Just to clarify, you mean remove the c from the formail line,
from the formail-invoking recipe, yes. That's the only location you HAVE a
'c' flag in what you posted...
but leave the /dev/null line (sans filelock), in case the formail
fails? Is there any reason why a failure would continue on in
the rule?
Failure to invoke formail, and possibly sendmail...
And does that mean that I should include 'w' in the "| formail" rule?
That'd be one way to guard against it.
The reason you're getting the write error is that formail
isn't reading in the entire message. Procmail is expecting
to write the headers and MASSIVE body, but the invocation
of formail is telling it to just process the headers.
Yes, that makes sense. I think I assumed that formail would
drop the body anyway, so it didn't matter, but I see now that
this adds more work to procmail, thus slowing things down.
Well, sorta. Formail _does_ drop the body - by NOT READING IT. Procmail
however sees that the message it was prepared to write to the pipe wasn't
read completely.
Some other reccommendations: if rejection_notice isn't a valid
address, don't set the envelope sender to be that anyway.
It is valid (it is an alias to the my email addy).
Formatting your message to be similar to a mailer-daemon bounce and sending
it from mailer-daemon would reduce the likelyhood that some tosser mail
system will REPLY to it with an automated notice... Your custom address
doesn't carry that benefit.
in fact, you should set it to be postmaster (which is a better
option than mailer-daemon, unless your bounce message is
formulated so as to mimic a 'standard' bounce for oversized
messages).
The reason for setting it to 'rejection_notice' is because we
deal with a lot of clientelle who are not computer literate, and
my thought is that the email message, which is returned, should
be as obvious as possible that it is, in fact, a rejection notice.
This should be obvious even before they open the message to read
the body.
Have you considered using the SUBJECT line to convey this?
Have you considered just enabling the message size limits in
your MTA?
(= If I knew how, I would have done this in the first place. If
there is one thing that is more "magical" to me than procmail, it's
sendmail. I'm feel proud to just have sendmail working. (=
from the cf/README file in the sendmail source distro:
confMAX_MESSAGE_SIZE MaxMessageSize [infinite] The maximum size of
messages that will be accepted (in
bytes).
I won't get into how you'd set the configuration in your .mc config file
and rebuild, but it's rather straightforward (and preferred over hacking
the sendmail.cf directly, though you can certainly make a backup of it and
hack it to test it if you want, THEN go and build the .mc if you're not
already using it).
---
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 homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail