On 29 May 1999, Jerry Preeper <preeper(_at_)cts(_dot_)com> wrote:
I finally had to turn procmail off last night so I could get some
sleep.
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...
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?
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.
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.
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.
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
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.
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