Re: [Mimedefang] Greylisting problem with the default confTO_COMMAND
Quoting Paul Heinlein <[EMAIL PROTECTED]>: > On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote: > > > Which RFC(s) do these timeouts violate? > > RFC 1123, section 5.3.2. > > -- Paul Heinlein <[EMAIL PROTECTED]> I don't see any "MUST"s in there, just some "SHOULD"s. I don't think it violates it, since "there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course." One just has to know what one is doing before messing with this stuff, which is, in my opinion, a good rule to follow when it comes to email at all, and especially sendmail. -- Andrew ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Greylisting problem with the default confTO_COMMAND
On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote: > Which RFC(s) do these timeouts violate? RFC 1123, section 5.3.2. -- Paul Heinlein <[EMAIL PROTECTED]> ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Greylisting problem with the default confTO_COMMAND
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My intent is not to start a protracted argument over this but: The way I read RFC 1123, assuming you understand the implications of changing the sendmail timeout values and you are doing so for a valid reason, you are NOT in violation of the RFC to make those changes. /-From RFC 1123--/ Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows: oInitial 220 Message: 5 minutes oMAIL Command: 5 minutes oRCPT Command: 5 minutes oDATA Initiation: 2 minutes oData Block: 3 minutes oDATA Termination: 10 minutes. A receiver-SMTP SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender.A *"SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. // - -- EKB Linux: Because rebooting is for adding new hardware. On Thu, 26 Feb 2004 at 17:35 -0700, Lucas Albers at [EMAIL PROTECTED] said: > Violates RFC. I have never had any complainst in the 8 months or so I have > been using it. > > #max file size accepted is 50m > dnl TIMEOUTS (MANY OF THESE)... > define(`confTO_INITIAL', `10s') > define(`confTO_CONNECT', `30s') > define(`confTO_ICONNECT', `8s') > dnl set next 4 to 1m for more conservative settings > define(`confTO_HELO', `30s') > define(`confTO_MAIL', `30s') > define(`confTO_RCPT', `30s') > define(`confTO_DATAINIT', `30s') > define(`confTO_DATABLOCK', `1m') > define(`confTO_DATAFINAL', `3m') > define(`confTO_RESET', `1m') > define(`confTO_QUIT', `1m') > define(`confTO_MISC', `1m') > define(`confTO_COMMAND', `1m') > dnl #define(`confTO_IDENT', `1m') > define(`confTO_IDENT', `1s') > define(`confTO_FILEOPEN', `1m') > define(`confTO_CONTROL', `1m') > define(`confTO_HOSTSTATUS', `3m') > dnl DOS stuff > define(`confCONNECTION_RATE_THROTTLE', `8') > define(`confTO_IDENT', `0')dnl > dnl security stuff > dnl WARNING > dnl this is a mail relay so sendmail can ONLY WRITE TO /var > define(`confSAFE_FILE_ENV',`/var')dnl > define(`confMAX_HEADERS_LENGTH', `16384') > define(`confMAX_MIME_HEADER_LENGTH', `256/128') > define(`confMAX_DAEMON_CHILDREN', `12') > dnl 50meg max size > define(`confMAX_MESSAGE_SIZE', `50485760')dnl > -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAP4wSdY33sSC+/BERAqRVAJ9G8BRsgLd4RrH1d/zjoY5ZEuW3uACfchmu Lw0FGNE9oT+34kNxXs0DGUo= =Y+AS -END PGP SIGNATURE- ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Greylisting problem with the default confTO_COMMAND
[EMAIL PROTECTED] wrote on 02/27/2004 11:15:36 AM: > On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote: > > > Which RFC(s) do these timeouts violate? > > RFC 1123, section 5.3.2. Which states "Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:" The timeouts mentioned previously are much lower than the ones listed int eh RFC, but I don't see that as violating it. Network connections are also many orders of magnitude faster than they were in 1989, so adjusting the timeouts lower is probably not unreasonable. Back then, 9.6kb/s was screaming. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Greylisting problem with the default confTO_COMMAND
This whole section is advisory, being full of "SHOULD" entries, rather than "MUST" entries - see section 1.3.2 for details of the terminology. In addition, it has been superceded by technology, as the idea of waiting at least five minutes for a remote server to send a command is now simply ludicrous - in this age, anything which takes more than about five seconds can be assumed to have failed, and since we then give up on them and they try again, a temporary failure of an intervening connection is not good cause for us to keep a port open for five minutes in the vain hope that it will come back up again and also be able to carry on from where it left off. Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Greylisting problem with the default confTO_COMMAND
On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote: > Which RFC(s) do these timeouts violate? RFC 1123, section 5.3.2. -- Paul Heinlein <[EMAIL PROTECTED]> ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Greylisting problem with the default confTO_COMMAND
[EMAIL PROTECTED] wrote on 02/26/2004 07:35:21 PM: > I use these timeouts on a 5k a day mail server. > Got original timeouts from list that. Works for me. > Your mileage may vary. > Before I had timeouts modified I had too many slaves just hanging around > on my system. > > Violates RFC. I have never had any complainst in the 8 months or so I have > been using it. Which RFC(s) do these timeouts violate? ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Greylisting problem with the default confTO_COMMAND
Hi, I have implemented greylisting in filter_begin, it works great, but there is still an issue because there are some spam software that keep the connection open after they get temporary failure message. The sendmail default timeout to wait a command (confTO_COMMAND) is 1 hour, so if I set the max mimedefang processes and sendmail children to 50 (I think this is not too small for 30k mails/day), the mail relay will be often out of processes and can't accept any new mail because all 50 sendmail processes are used by mail clients that don't quit immediately after tempfailed. so I changed confTO_COMMAND to 5 minutes, and it helps, but I am not sure if it is ok. and actually not only some spam software keep the connection open after tempfailed, but I have seen also email from checkpoint.com that wait for an hour till disconnected by sendmail. I don't know which mail server do checkpoint use and if it understand that its mail get tempfailed by our mail relay. So I hope someone know about this issue. thanks, cahya. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Greylisting problem with the default confTO_COMMAND
I use these timeouts on a 5k a day mail server. Got original timeouts from list that. Works for me. Your mileage may vary. Before I had timeouts modified I had too many slaves just hanging around on my system. Violates RFC. I have never had any complainst in the 8 months or so I have been using it. #max file size accepted is 50m dnl TIMEOUTS (MANY OF THESE)... define(`confTO_INITIAL', `10s') define(`confTO_CONNECT', `30s') define(`confTO_ICONNECT', `8s') dnl set next 4 to 1m for more conservative settings define(`confTO_HELO', `30s') define(`confTO_MAIL', `30s') define(`confTO_RCPT', `30s') define(`confTO_DATAINIT', `30s') define(`confTO_DATABLOCK', `1m') define(`confTO_DATAFINAL', `3m') define(`confTO_RESET', `1m') define(`confTO_QUIT', `1m') define(`confTO_MISC', `1m') define(`confTO_COMMAND', `1m') dnl #define(`confTO_IDENT', `1m') define(`confTO_IDENT', `1s') define(`confTO_FILEOPEN', `1m') define(`confTO_CONTROL', `1m') define(`confTO_HOSTSTATUS', `3m') dnl DOS stuff define(`confCONNECTION_RATE_THROTTLE', `8') define(`confTO_IDENT', `0')dnl dnl security stuff dnl WARNING dnl this is a mail relay so sendmail can ONLY WRITE TO /var define(`confSAFE_FILE_ENV',`/var')dnl define(`confMAX_HEADERS_LENGTH', `16384') define(`confMAX_MIME_HEADER_LENGTH', `256/128') define(`confMAX_DAEMON_CHILDREN', `12') dnl 50meg max size define(`confMAX_MESSAGE_SIZE', `50485760')dnl Cahya Wirawan said: > Hi, > I have implemented greylisting in filter_begin, it works great, > but there is still an issue because there are some spam software > that keep the connection open after they get temporary failure message. > The sendmail default timeout to wait a command (confTO_COMMAND) is > 1 hour, so if I set the max mimedefang processes and sendmail children > to 50 (I think this is not too small for 30k mails/day), the mail relay > will be often out of processes and can't accept any new mail because > Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
