Re: Help ASAP: queued message, disk full, general chaos
At 10:07 PM 2/22/99 +, Robin Bowes wrote: >It says: > > "If the environment variable DATABYTES is set, it overrides >databytes." > >...which I knew already. > >I'm not sure where this would be set; presumably using a rule in the cdb No. You set the limit in the environment variable. 1.2.3.4:allow,DATABYTES="100" >file used by tcpserver? This would only set the limit based on IP >address, would it not? > >I was wondering how it could be done on a per-user basis? If you cannot identify the user by IP, there is no standard way. In fact, how do you identify the user if not by IP? Surely not be the trivially easy to forge envelope address? Regards. > >R. > >Scott Schwartz wrote: >> >> Robin Bowes <[EMAIL PROTECTED]> writes: >> | Is it possible to restrict incoming message sizes on a per-user basis >> | (strictly speaking, on a "per address" basis since we don't have any >> | "users" as such) ? >> >> What does the man page for qmail-smtpd say? > >-- >Two rules to success in life: > 1. Don't tell people everything you know. > -- Sassan Tat > >
Re: Help ASAP: queued message, disk full, general chaos
Robin Bowes writes: > I was wondering how it could be done on a per-user basis? So are we. SMTP is an unauthenticated protocol. A number of people have devised ad-hoc methods for identifying users, but none of them are wholly satisfactory. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: Help ASAP: queued message, disk full, general chaos
It says: "If the environment variable DATABYTES is set, it overrides databytes." ...which I knew already. I'm not sure where this would be set; presumably using a rule in the cdb file used by tcpserver? This would only set the limit based on IP address, would it not? I was wondering how it could be done on a per-user basis? R. Scott Schwartz wrote: > > Robin Bowes <[EMAIL PROTECTED]> writes: > | Is it possible to restrict incoming message sizes on a per-user basis > | (strictly speaking, on a "per address" basis since we don't have any > | "users" as such) ? > > What does the man page for qmail-smtpd say? -- Two rules to success in life: 1. Don't tell people everything you know. -- Sassan Tat
Re: Help ASAP: queued message, disk full, general chaos
Robin Bowes <[EMAIL PROTECTED]> writes: | Is it possible to restrict incoming message sizes on a per-user basis | (strictly speaking, on a "per address" basis since we don't have any | "users" as such) ? What does the man page for qmail-smtpd say?
Re: Help ASAP: queued message, disk full, general chaos
Robin Bowes writes: > Russell Nelson wrote: > > > > Incoming is easy: stuff the size into a decimal number stored in > > control/databytes. That will tell qmail-smtpd to refuse mail that > > large. Outgoing is a little tougher if you have user accounts. > > Is it possible to restrict incoming message sizes on a per-user basis > (strictly speaking, on a "per address" basis since we don't have any > "users" as such) ? Yes. Set the DATABYTES environment variable for some hosts using tcpserver's control file. If you set it to zero, that disables limiting. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: Help ASAP: queued message, disk full, general chaos
Russell Nelson wrote: > > Incoming is easy: stuff the size into a decimal number stored in > control/databytes. That will tell qmail-smtpd to refuse mail that > large. Outgoing is a little tougher if you have user accounts. > Is it possible to restrict incoming message sizes on a per-user basis (strictly speaking, on a "per address" basis since we don't have any "users" as such) ? R. -- Two rules to success in life: 1. Don't tell people everything you know. -- Sassan Tat
Re: Help ASAP: queued message, disk full, general chaos
Chris Hardie writes: > Howdy; please help ASAP: We're running Qmail on FreeBSD 2.2.8. Someone > sent a 17 MB message to one of our users. /var, where qmail is located, > is only a 30 MB partition, and with that message sitting in the queue, > only has about 3 MB left on it. > > In the maillog, the message > > deferral: Unable_to_forward_message :_qq_write_error_or_disk_full_(#4.3.0)./ > > appears repeatedly. There's plenty of space on the user's partition and > their quota will allow for the message just fine. It appears that qmail > somehow needs to re-write the message somewhere in it's own hierarchy on > the same partition before it can forward it on. Looks to me like the user has a .qmail file which says '&somebodyelse', because qmail-local is trying to re-queue the message for another delivery, and failing. > I tried reducing the queue lifetime so the message would bounce, but qmail > can't bounce it either, the same messages of "file system full" keep > appearing. Well yes, that wouldn't work either, because it can't inject the bounce. > I tried (much to your dismay) to move the queue directory to another > partition, and got an error message at startup about "cannot start: unable > to open mutex" so I didn't pursue that any further (can anyone say what > "mutex" is?) Yes, qmail tries to open a file mutually exclusively, as a lock. > So, I'd *really* like to know: > 1) In the short term, is there a way to deliver or bounce this message > without just deleting the queue file manually? Deliver yes, but not forward. > 2) In general, did this problem arise because we improperly installed > qmail to a small partition, or is there something about qmail that should > be better in handling large messages (i.e. file system full problems) > that it can't really handle? Well, it's handling it as best it can, given the lack of space. > 3) If it's a disk space issue, is there a way to have the queue > directory somewhere else or do we need to move the whole ball of wax? You can put /var/qmail/queue on a different filesystem. > 4) Is there a way to restrict incoming/outgoing message size? Incoming is easy: stuff the size into a decimal number stored in control/databytes. That will tell qmail-smtpd to refuse mail that large. Outgoing is a little tougher if you have user accounts. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: Help ASAP: queued message, disk full, general chaos
This may have already been covered, but if I'm desperate for space on /var/qmail, I've been known to trash move everything out of /var/qmail (except /var/qmail/qmail) to another FS and symlink back. That usually gives me enough space and inodes to start draining the queue. Regards. At 09:12 PM 2/20/99 -0500, Scott Schwartz wrote: >"Fred Lindberg" <[EMAIL PROTECTED]> writes: >| >Of course it is trivial. There's no reason to include the body of a >| >message in the bounce. Just send the first, say, 4k, of the message, >| >| Quite hard to do when there is no space. You can't remove the old >| message before you've queued the bounce. > >True; in pathological cases you should probably just treat it as a >triple bounce and discard it. However, it's likely that there is >*some* space, so a 4K bounce for a 20M message is less likely to fail >than a 20M bounce. > > >
Re: Help ASAP: queued message, disk full, general chaos
"Fred Lindberg" <[EMAIL PROTECTED]> writes: | >Of course it is trivial. There's no reason to include the body of a | >message in the bounce. Just send the first, say, 4k, of the message, | | Quite hard to do when there is no space. You can't remove the old | message before you've queued the bounce. True; in pathological cases you should probably just treat it as a triple bounce and discard it. However, it's likely that there is *some* space, so a 4K bounce for a 20M message is less likely to fail than a 20M bounce.
Re: Help ASAP: queued message, disk full, general chaos
On 20 Feb 1999 14:13:41 -0500, Scott Schwartz wrote: >Of course it is trivial. There's no reason to include the body of a >message in the bounce. Just send the first, say, 4k, of the message, Quite hard to do when there is no space. You can't remove the old message before you've queued the bounce. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Re: Help ASAP: queued message, disk full, general chaos
- Scott Schwartz <[EMAIL PROTECTED]>: | Harald Hanche-Olsen <[EMAIL PROTECTED]> writes: | | I'll say a 30 MB partition is a mite small, yes. But also, it is true | | that qmail doesn't gracefully handle the sort of situation you are | | describing. Making it do so is not a trivial task, however. | | Of course it is trivial. There's no reason to include the body of a | message in the bounce. What I had in mind is the case of a message that wants to be forwarded, but which is too big to fit in queue twice. I agree that cutting back the size of bounce messages is trivial in comparison. - Harald
Re: Help ASAP: queued message, disk full, general chaos
Harald Hanche-Olsen <[EMAIL PROTECTED]> writes: | I'll say a 30 MB partition is a mite small, yes. But also, it is true | that qmail doesn't gracefully handle the sort of situation you are | describing. Making it do so is not a trivial task, however. Of course it is trivial. There's no reason to include the body of a message in the bounce. Just send the first, say, 4k, of the message, and rely on the sender to have saved a copy if they want to resend. If you are receptive to creeping features, qmail could try to send the whole useless message body, and fall back to just the headers if that fails.
Re: Help ASAP: queued message, disk full, general chaos
- Chris Hardie <[EMAIL PROTECTED]>: | Howdy; please help ASAP: We're running Qmail on FreeBSD 2.2.8. | Someone sent a 17 MB message to one of our users. /var, where qmail | is located, is only a 30 MB partition, and with that message sitting | in the queue, only has about 3 MB left on it. | | In the maillog, the message | | deferral: Unable_to_forward_message :_qq_write_error_or_disk_full_(#4.3.0)./ | | appears repeatedly. There's plenty of space on the user's partition | and their quota will allow for the message just fine. It appears | that qmail somehow needs to re-write the message somewhere in it's | own hierarchy on the same partition before it can forward it on. Yes indeed, forwarding a message means requeueing it. | I tried reducing the queue lifetime so the message would bounce, but | qmail can't bounce it either, the same messages of "file system | full" keep appearing. No surprise there. | I tried (much to your dismay) to move the queue directory to another | partition, and got an error message at startup about "cannot start: | unable to open mutex" so I didn't pursue that any further (can | anyone say what "mutex" is?) Ouch. Moving the queue directory is *dangerous*: There is not only the special files in queue/lock/, but certain files need to have their name and inode numbers matching, or else. | So, I'd *really* like to know: | 1) In the short term, is there a way to deliver or bounce this | message without just deleting the queue file manually? That's what I have done in similar situations. Stop the queue, move all the files concerning the big message to a different file system, and restart qmail. Now at least other mail can flow freely again. Second, figure out the real destination address of the the problem message and reinject it manually using qmail-inject -a -f$SENDER $RECIPIENT where you replace $SENDER and $RECIPIENT by the envelope sender and recipient, respectively (you can find these in the other files associated with the message, namely info/*/# and local/*/#. Except, of course, you must now supply the forwarding address, so the message doesn't have to be regurgitated through the queue again. | 2) In general, did this problem arise because we improperly | installed qmail to a small partition, or is there something about | qmail that should be better in handling large messages (i.e. file | system full problems) that it can't really handle? I'll say a 30 MB partition is a mite small, yes. But also, it is true that qmail doesn't gracefully handle the sort of situation you are describing. Making it do so is not a trivial task, however. | 3) If it's a disk space issue, is there a way to have the queue | directory somewhere else or do we need to move the whole ball of | wax? I think there is no problem with having /var/qmail/queue being a symlink to a directory on a different filesystem. On the other hand, the queue at its largest is usually vastly larger than the rest of the qmail files combined, so I would generally recommend moving the whole shebang. In my opinion, mail is so important it pays to have a separate filesystem for it. If you can spare a disk partition, mount it on /var/qmail and put everything there. The best way to get it back in operation, is to reinstall qmail (just run `make setup') and then to copy everything from the old alias and control directories to the new partition. Finally, if there were messages in the old queue, copy them to the new queue (*all* files) and run the queue-fix program (link at http://www.qmail.org/>). DON'T forget this last step, as starting the qmail daemons, or even allowing qmail-queue to run with the queue in a wrong state, can result in a corrupted queue and lost mail. | 4) Is there a way to restrict incoming/outgoing message size? Incoming, yes. Use control/databytes (RTFM qmail-smtpd). - Harald
