qmail Digest 9 Apr 2000 10:00:00 -0000 Issue 966
Topics (messages 39768 through 39776):
Re: HELO in
39768 by: Claus Färber
Re: Doubts: qmail and IMAP
39769 by: Claus Färber
re : account locking
39770 by: Shaun Gibson
SMTPd questions...
39771 by: Scott D. Yelich
Re: Vapormail (was: Re: Problem: 552 max. message size exceeded)
39772 by: Frank D. Cringle
Mini-survey on RFC 1651/1869 compliancy
39773 by: Andrzej Kukula
39776 by: Magnus Bodin
supervise: fatal: unable to acquire log/supervise/lock
39774 by: Peter Janett
39775 by: lluisma
Administrivia:
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
A. Yahya Sjarifuddin <[EMAIL PROTECTED]> schrieb/wrote:
> Is there any incomptability with Lotus or just wrong setting?
> Thanks for any help.
>
>>> <[EMAIL PROTECTED]>:
>>> Connected to 202.103.147.133 but sender was rejected.
>>> Remote host said: 500 Session already established. The domain name
>>[smtp-a.cbn.net.id] passed in with HELO will be ignored. The current domain
>>name of sending SMTP is [www.wtwh.com.cn].
The software that produced this error message is not SMTP-compliant.
Tell them to use software that conforms to accepted internet standard if
they want to receive email.
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
Gilberto Rodrigues <[EMAIL PROTECTED]> schrieb/wrote:
> 1. I'm following the BUILD doc and according to it, I should install the
> pop2d, pop3d and imapd daemons in a system directory of my choosing. Is
> it necessary to install the pop2d and pop3d daemons? What are they for?
> Must all of them be running even if I wanna have only IMAP protocol?
Of course not.
> 2. According to the docs, I should update inetd.conf to invoke the
> daemons. I guess I could use tcpserver instead of editing it. Is it
> correct? Does IMAP daemon have to appear before qmail's dameons in init
> scripts?
No, it does not matter: qmail can run without imapd and vice-versa. They
can even be on different machines (if the maildir is mounted in some way
on both).
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
configuration :
qmail and qmail ldap patch
qmail pop3d
how about this :
- add a status entry for ldap
- if the entry is set create a dummy maildir with one new email
(this means that all mail to the locked mailbox will still be
delivered but will be unavailable until the status entry from ldap is
reset)
- have a script to clean up all the dummy maildirs
--
Shaun Gibson
------------------------------------------------------------------------------------
Associate Unix and NT System Adminstrator Tel :
+27-11-2667800 ext 8023
Intekom, Midrand, South Africa
-----------------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE-----
(1) Is it better to write an SMTPd that is strict to the RFCs or
lenient? That is, where does one go to settle disputes -- or is it
better to sit back and miss mail due to differences in interpreting
the RFCs? Ie: if an smtpd accepts bare linefeeds, etc., is that
really all that bad on incoming? what about then when sending mail,
should one write a "smart" sender, or just a simple one
that tries to be as standard as possible?
(2) Are there any tools to thoroughly test a prospective SMTPd
against RFC compliance? Is anyone interested in such a tool?
(3) qmail accepts "mail from:" and "rcpt to:" without parameters. The
"data" command is then allowed, a message body can be entered, and is
accepted with a 250 after the dot line. Is this correct?
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOO+B/lpGPE+AF6qBAQHUEwP/W4ItK1J3Rl8szGaTI+hAG0yaVy+5Rtn4
ntdY/LFlIe/riMQAZfm9l14CxXtHp/oWt1KC3SyPsG2HCH3Z/uKMOE7j4MqUzROG
AjRkq+9P4bZMfgF/VcGrj2HfK7cm68opED+UUPSRkuCbb9zGQhNm4U0uZQ5tyNnL
Qsd2u7IwVMQ=
=Q/sk
-----END PGP SIGNATURE-----
Dave Sill <[EMAIL PROTECTED]> writes:
> "Soffen, Matthew" <[EMAIL PROTECTED]> wrote:
> >I mean, How do you go from postfix to mail server (at least qmail and
> >sendmail have the word MAIL in their titles).
>
> Well, "post" is "mail", and "fix", well, I guess that means it fixes
> mail problems (namely sendmail :-).
"fix" is colloquial for "quick" or "snappy" in German and possibly also in
Dutch. Maybe that influenced Wietse's choice.
--
Frank Cringle, [EMAIL PROTECTED]
voice: (+49 2304) 467101; fax: 943357
I don't see this topic discussed in the list archive.
When sending a mail message from some ESMTP clients to some ESMTP servers,
and the network or the server is highly congested, it is possible that the
message will be deferred as a result of RFC 1651/1869 inherent bug that
leads to "503 Duplicate HELO/EHLO" from an ESMTP server.
The following ia an example of an ESMTP session. C stands for an ESMTP
client, S for an ESMTP server implementing that buggy behavior:
S: 220 [greeting]
C: EHLO client.example.org [tries to negotiate ESMTP]
S: [not responding in expected time]
C: HELO client.example.org [tries to estabilish plain SMTP]
S: 250-server.example.org [responds to the EHLO]
S: 250-[ESMTP features]
S: 250 8BITMIME
S: 503 Duplicate HELO/EHLO [responds to the HELO]
C: QUIT
Exchange Server SMTP Service version 5.5 is an example of client working
that way. It tries to negotiate ESMTP features where available (e.g. to not
attempt to send message when its size exceeds RFC 1427's SIZE), or sends
message via plain SMTP otherwise.
The bug in RFC 1869 may be explained as follows:
1. RFC 1869 extends RFC 821 (look at p. 4.1).
2. RFC 821 p. 4.1.1 (page 27) allows using HELO multiple times during
a session. RFC 821 p. 4.1.1 (page 19) defines conditions under which
HELO returns positive or negative response.
3. RFC 1869 p. 4.2 says an EHLO may be issued at any time that a HELO
would be appropriate.
4. RFC 1869 p. 4.2 then denies itself saying that after a successful
server response to first EHLO, all subsequent HELO/EHLOs must return
error 503.
Here are my own mini-survey on (E)SMTP servers and their buggy-RFC-1869
behavior:
+-----------------------------------------------+-----------------+
| (E)SMTP server software name | RFC 1869 bug? |
+-----------------------------------------------+-----------------+
| qmail 1.03 | no |
| ZMailer 2.99.52-patch1 | no |
| Exim 2.12 | no |
| MS SMTP Mail 5.5.* | no |
| MailShield SMTPCisco SMTP Gateway | no |
| America Online mail version 71.10 | no |
| HotMail ESMTP server | no |
| Lotus Domino 5.0.2a ESMTP Service | no |
+-----------------------------------------------+-----------------+
| sendmail 8.8.8, 8.9.1, 8.9.3 | YES |
| Postfix up to snapshot 20000309 | YES |
| Mercury 1.44 | YES |
| Rayan S. Zachariassen ESMTP Server (mail.net) | YES |
+-----------------------------------------------+-----------------+
| CheckPoint FireWall-1 Secure SMTP Server | plain SMTP only |
| MudMail 1.71 | plain SMTP only |
| GroupWise Internet Agent 5.5.3.1 | plain SMTP only |
+-----------------------------------------------+-----------------+
"no" in the second column means that the server allows multiple HELOs/EHLOs
per session. "YES" means the server is affected by the issue. "Plain SMTP
only" means EHLO wasn't accepted by the server.
As you know, qmail accepts mail from client that doesn't issue HELO/EHLO at
all. Now it is clear that qmail also accepts mail when others fail.
Regards,
Andrzej Kukula
On Sun, Apr 09, 2000 at 01:40:33AM +0200, Andrzej Kukula wrote:
>
> Here are my own mini-survey on (E)SMTP servers and their buggy-RFC-1869
> behavior:
[very interesting stuff deleted]
> +-----------------------------------------------+-----------------+
> | (E)SMTP server software name | RFC 1869 bug? |
> +-----------------------------------------------+-----------------+
> | qmail 1.03 | no |
> | ZMailer 2.99.52-patch1 | no |
> | Exim 2.12 | no |
> | MS SMTP Mail 5.5.* | no |
> | MailShield SMTPCisco SMTP Gateway | no |
> | America Online mail version 71.10 | no |
> | HotMail ESMTP server | no |
> | Lotus Domino 5.0.2a ESMTP Service | no |
> +-----------------------------------------------+-----------------+
> | sendmail 8.8.8, 8.9.1, 8.9.3 | YES |
> | Postfix up to snapshot 20000309 | YES |
> | Mercury 1.44 | YES |
> | Rayan S. Zachariassen ESMTP Server (mail.net) | YES |
> +-----------------------------------------------+-----------------+
> | CheckPoint FireWall-1 Secure SMTP Server | plain SMTP only |
> | MudMail 1.71 | plain SMTP only |
> | GroupWise Internet Agent 5.5.3.1 | plain SMTP only |
> +-----------------------------------------------+-----------------+
FYI: "InterMail vM.4.01.02.17" also allows multiple HELOs/EHLOs, i.e.
"no" to "RFC 1869 bug".
/magnus
I have been installing Qmail on a new Solaris box. I have gone through the
install instructions at:
http://Web.InfoAve.Net/~dsill/lwq.html#installation
I installed the startup script located at:
http://Web.InfoAve.net/~dsill/qmail-script-dt61.txt
Things seemed to be going fine until I tried to start qmail with:
/usr/local/sbin/qmail start
I get the following every few seconds, over and over, until I kill the
svscan ID:
supervise: fatal: unable to acquire log/supervise/lock: temporary failure
supervise: fatal: unable to acquire qmail-smtpd/supervise/lock: temporary
failure
supervise: fatal: unable to acquire log/supervise/lock: temporary failure
I checked the archives, and found a few similar errors, but they said
"permission denied" where I am getting "temporary failure".
Any help GREATLY appreciated.
Thanks,
Peter Janett
New Media One Web Services
~Professional results with a personal touch~
http://www.newmediaone.net
[EMAIL PROTECTED]
(303)828-9882
Peter Janett wrote:
> I have been installing Qmail on a new Solaris box. I have gone through the
Solaris 7? or 8?
What C compiler?
Show me your PATH.
I was able to make it to work on 7 but not on 8.
>
> install instructions at:
> http://Web.InfoAve.Net/~dsill/lwq.html#installation
>
> I installed the startup script located at:
> http://Web.InfoAve.net/~dsill/qmail-script-dt61.txt
>
> Things seemed to be going fine until I tried to start qmail with:
> /usr/local/sbin/qmail start
>
> I get the following every few seconds, over and over, until I kill the
> svscan ID:
>
> supervise: fatal: unable to acquire log/supervise/lock: temporary failure
> supervise: fatal: unable to acquire qmail-smtpd/supervise/lock: temporary
> failure
> supervise: fatal: unable to acquire log/supervise/lock: temporary failure
>
> I checked the archives, and found a few similar errors, but they said
> "permission denied" where I am getting "temporary failure".
>
> Any help GREATLY appreciated.
>
> Thanks,
>
> Peter Janett
>
> New Media One Web Services
> ~Professional results with a personal touch~
> http://www.newmediaone.net
> [EMAIL PROTECTED]
> (303)828-9882
