At 12:53 11/01/99 +0800, Shing-Gene Yung wrote:
>On Mon, 11 Jan 1999, Harald Hanche-Olsen wrote:
>
>> | FreeBSD). The DU system started spawning a lot of qmail-smtpd and
>> | ...
>> | I should have ulimited the qmail daemons? Or was there something
>> | else I could have done?
>>
>> Use the -c option to tcpserver to limit the number of incoming
>> connections.
>
>only snag is: I don't use tcpserver...or at least I can't. I tried
>tcpserver at one time but it turned out that it would reject mail
>forwarded from an MS exchange server. I don't remember the exact error but
>once I switched back to inetd it was ok. I'll try and dig up that error
>msg again...maybe you guys can tell me what's wrong :)
You might have a buggy version of inetd on the DU box. It's also possible
that this was a direct denial of service attack. I'd bet my money on the
FreeBSD box outlasting the DU box in any DOS attack that affects both systems.
>> | What does qmail do when it is unable to complete sending a message
>> | to another qmail server?
>>
>> The message remains in the queue and are retried for up to a week.
>> (This is guaranteed, as long as the file system is intact and no ones
>> messes with the queue.)
>
>Ok, so if the sending qmail receives an OK from the recipient qmail it
>will delete the message from its (sending) queue. If a message is in the
>process of sending but the recipient smptd crashes, then the sending
>qmail-remote times-out and keeps the msg in the queue to be re-tried again
>later. Is that right?
Sounds right. Occasionly this could lead to (in very rare situations)
double ups, but it avoids loss of mail, which is the primary concern
Stuart Young - [EMAIL PROTECTED] - [EMAIL PROTECTED]
(aka Cefiar) - http://amarok.glasswing.com.au/
[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]
