Thanks again to everyone for all the help. The big problem seems to be I
needed to upgrade procmail from 3.11.pre7 to 3.13.1 mainly because of the
problem with allocating memory on FreeBSD systems. Looks like everything
is starting back to normal
..snip
This morning I added this line in sendmail.cf
O MaxMessageSize=10000000
to allow reasonably size messages through (I pretty regularly get some
5 - 7MB messages).
You might want to keep in mind that a Base64-encoded or a UUencoded
file is roughly 35% larger than the initial file. So a 10Mb size limit
in sendmail will let messages with 7Mb attachments pass through, but
will block the ones with 8Mb attachments.
However, if I'm allowed to express a personal opinion here, I think
your operation model is flawed. Since you give people permission to
send 10Mb files by e-mail, you can't realistically expect them to see
anything wrong with sending 50Mb ones...
Yes and no. Sending a 50MB file via email is not the most efficient way to
transfer the file. Especially on slower connections. Unfortunately not
everyone realizes this or understands / uses ftp. This email just brought
to light that I need to upgrade procmail from 3.11.pre7 because of the
problem with memory allocation on FreeBSD systems and teach this particular
client about ftp. If the upgrade of procmail solves the problem, I'll
remove the max message size and let the quota system determine what they
can and can not get. In this instance, however, they are transferring
graphic design files for artwork just before a holiday weekend and I can't
get in touch with anybody.
I also added the person sending this message email address to my
/etc/mail/access file
name(_at_)domain(_dot_)com 550 Contact Webmaster Immediately at
preeper(_at_)cts(_dot_)com
Ahem, so how is he supposed to mail you back if you're blocking his
address?
That particular email address is not on this particular server - which is
one of the main reasons I keep it.
And since we are in the middle of my favorite activity (nitpicking,
that is), you might also want to change the 550 code. Sendmail has
always treated 550 as a catch-all instead of 554 (and encouraged people
to do that too), but according to RFC 821 this is wrong:
: 550 Requested action not taken: mailbox unavailable
: [E.g., mailbox not found, no access]
: 551 User not local; please try <forward-path>
: 552 Requested mail action aborted: exceeded storage allocation
: 553 Requested action not taken: mailbox name not allowed
: [E.g., mailbox syntax incorrect]
: 554 Transaction failed
The appropriate code in your case seems to be 554.
Absolutely correct, but I was in a hurry to try and keep my box alive.
I have also emailed the person with info on an ftp account they can
use, but it's a holiday weekend and I doubt I'll get a response. My
real problem is the outgoing mail server at their site that keeps
trying to send this huge message.
A mailer that doesn't give up when it sees a 550 code is broken
beyond all hope. Are you absolutely sure your access_db configuration
is ok?
I ran newaccess and restarted sendmail with a killall -1 sendmail and
turned procmail back on and this message still seems to be getting
processed by procmail.
"newaccess" is not a standard utility; I assume it calls
makemap hash /etc/mail/access < /etc/mail/access
somewhere. Also, you shouldn't send a HUP to _all_ sendmail processes,
just to the one that is listening for new connection. You should also
kill the thread that is reading the offending message (use netstat to
find out which is that). A simpler approach is to just stop and restart
sendmail.
Yes, that is exactly what newaccess is. Your'e probably right on not
sending the HUP to all the sendmail processes, unfortunately that is how I
learned to do it and I'm learning that in the real world things are a bit
different.
The sending server keeps trying I assume because it never finished
successfully sending it (gee thanks).
Like I said, you should kill the thread which is doing that.
I have procmail set as my local delivery agent in sendmail.cf like this
Mlocal, P=/usr/bin/procmail, F=lsfSDFMAh5:/|qmn9, S=10/30, R=20/40,
T=DNS/RFC822/X-Unix,
A=procmail -a $h -d $u
Running sendmail 8.9.2 and procmail 3.11pre7 (I'm going to try and
upgrade to both sendmail 8.9.3 and procmail 3.13.1 this weekend) on a
FreeBSD 2.2.8-Stable system.
I now have two questions (with procmail turned off again). I read
somewhere there is a procmail_mailer_max flag that can possibly be
used with sendmail.
1) Can I somehow modify my sendmail setting just above to include this
option and if so how?
Theoretically, you should add something like
define(`PROCMAIL_MAILER_MAX', `10000000')
to the mc file you use to generate your sendmail.cf (it should go before
any reference to procmail), but for some reasons it doesn't appear to
have any effect in 8.9.3. Looking at the sources, it's supposed to add
M=10000000
after the "T=DNS/RFC822/X-Unix" entry --- but please note that by the
time sendmail gets to read that the offending message is already in your
local queue.
Now I'm ready to upgrade to 8.9.3 I think from 8.9.2 and try and
reconfigure everything, after I test out the procmail upgrade on some large
emails.
2) Since I know who this message is going to and who it is from, is
there an example of an rc file somewhere that will allow me to check
for any messages to this user and from the sender and if it is found,
then skip all the other rc files completely and just deliver the
messag?
:0:
* ^From:[ ]+sender
* ^TO_recipient
junk
Thanks.
I'm guessing all the processing of the rc files is probably where the
system is crashing? At least this way I can stop this particular
message until I upgrade everything and get it all working right.
You are guessing wrong, procmail crashes because it tries to read
the whole message in memory. You might consider switching to maildrop
(http://www.geocities.com/SiliconValley/Peaks/5799/maildrop.README.html)
if you don't like that approach.
I'll take a look at that.
Thanks again for the assistance.
HTH.
Regards,
Liviu Daia
--
Dr. Liviu Daia e-mail: Liviu(_dot_)Daia(_at_)imar(_dot_)ro
Institute of Mathematics web page: http://www.imar.ro/~daia
of the Romanian Academy PGP key: http://www.imar.ro/~daia/daia.asc