19482 - exim server's response to 'RCPT TO:' not handled properly

Status: RESOLVED INCOMPLETE

(MailNews Core :: Networking: SMTP, defect, P5)

Description

[Dave Royal]

I cannot send any mail. I always get a message like
"An (SMTP) error occurred while sending mail. Server responded
<[e-mail]> is syntactically correct"
where '[e-mail]' was the 'to' address - ie myself, and it
*does* say 'correct'.
(This happens with any 'to' address.)
I have read bugs 18084 & 19026 - is this a case of the latter?
Mozilla pref lines:
user_pref("mail.smtp_name", "royal");
user_pref("mail.smtpserver.smtp1.hostname", "relay.freeuk.net");
user_pref("mail.smtpserver.smtp1.username", "royal");
(Same result if I delete the last of those)
They were converted from NC4.5 prefs:
user_pref("mail.smtp_name", "royal");
user_pref("network.hosts.smtp_server", "relay.freeuk.net");
Build ID 1999111520
Windows 95

Comment 1

[Jean-Francois Ducarroz]

I just sent a message to [e-mail] and apparently works fine. I reassign this bug to sspizter

Comment 2

[Dave Royal]

Attachment: Further tests which seem to confirm SMTP server config issue

Comment 3

[(not reading, please use [e-mail] instead)]

mark m13, accepting.

Comment 4

[Phil Peterson]

Based on the attachment, it appears that this is a server configuration error. I
don't think the error message is coming from mozilla -- I think it's coming from
the server. Marking invalid.

Comment 5

[edwin]

I just saw this error too. The server is exim v2.05 on FreeBSD with a fairly
standard setup.

Doing a manual smtp session:

> [10:20:27 edwin@wit387304 edwin] telnet localhost 25
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> 220 wit387304.student.utwente.nl ESMTP Exim 2.05 #1 Tue, 21 Dec 1999 10:22:50
+0100
> HELO woudt.nl
> 250 wit387304.student.utwente.nl Hello localhost [127.0.0.1]
> MAIL FROM:<[e-mail]>
> 250 <[e-mail]> is syntactically correct
> RCPT TO:<[e-mail]>
> 250 <[e-mail]> is syntactically correct
> DATA
> ....

Instead of the standard '250 ok', this mailserver apparently replies a bit
different. However a 250 result code already implies that the message was sent
ok, so mozilla should not care. This is also specified in RFC821 (SMTP):

> The number is intended for use by automata to determine what state to enter
> next; the text is meant for the human user.  It is intended that
> the three digits contain enough encoded information that the
> sender-SMTP need not examine the text and may either discard it or
> pass it on to the user, as appropriate.

Because of this violation of RFC821 I'm reopening this bug.

PS: The error shown is the error for the recipient (RCPT TO), apparently mozilla
already accepts the reply for the sender (MAIL FROM).

Comment 6

[edwin]

Hmm... I just looked at the code (mailnews/compose/src/nsSmtpProtocol.cpp) and
it seems correct.

Comment 7

[Dave Royal]

Attachment: Log of telnet STMP session with relay.freeuk.com

Comment 8

[Dave Royal]

I tried telnet session with relay.reeuk.net - same result as Edwin. See
attachment.

I sent a message with two recipients and it reported, in the error box, the
email address in the second one, so it does apppear to accept the RCPT TO
command. This suggests to me that the "syntactically correct" text is hanging
around and being incorrectly displayed as a result of some later error. However,
the next reply, 354, and the rest of the session looks OK to me. Tricky.

Comment 9

[(not reading, please use [e-mail] instead)]

moving to m14.

Comment 10

[(not reading, please use [e-mail] instead)]

marking p2

Comment 11

[(not reading, please use [e-mail] instead)]

moving to m15

Comment 12

[Dave Royal]

Just keeping this bug alive.
I've now tried it with M14 under Linux.
Different error message: "Alert: Sending of message failed"
Same SMTP server (relay.freeuk.net) as before.

Comment 13

[(not reading, please use [e-mail] instead)]

sliding to m16.  sorry everyone.  too many bugs, not enough time.

Comment 14

[selmer (gone)]

Is there an actual bug here?  Please describe what needs to be fixed.  Marking 
M17.

Comment 15

[edwin]

Well.... Mozilla mailnews does not work with exim.
It's not a server configuration problem, it is mozilla that does not accept a 
valid (according to RFC821) response to the 'RCPT TO:' command.

My comments from 1999-12-21 explain this in a little more detail.

Comment 16

[selmer (gone)]

Changing cryptic summary to reflect actual bug.  Nominating nsbeta2 since we're
not compliant with the RFC.

Comment 17

[(not reading, please use [e-mail] instead)]

I just tried sending a message to [e-mail], and my smtp server was
mail.sun.ac.za (ESMTP Exim 2.10)

I had no problems.

250 mail.sun.ac.za Hello h-198-93-95-225.netscape.com [198.93.95.225]
MAIL FROM:<netscape.com>  
250 <[e-mail]> is syntactically correct
RCPT TO:<[e-mail]>
250 <[e-mail]> is syntactically correct
DATA

are you still seeing this bug?  is so, do you have a server I can use to
reproduce?

Comment 18

[edwin]

You can use 130.89.234.74 (idefix.student.utwente.nl) and send messages to 
[e-mail] (they will be sent to you).

I'm currently downloading the latest nightly build.

Comment 19

[edwin]

Ok, this is interesting. Sending mail still fails, however I now get this error.
I can't really make sense of it...

| An error occurred sending mail: SMTP server error. The server responded:
| wit387304.student.utwente.nl Hello woudt.nl [10.235.121.14]
| SIZE
| PIPELINING
| HELP Contact your administrator for assistance.

Comment 20

[edwin]

Apparently the error above only happens the first time. On all subsequent 
attempts I get this error:

| An (SMTP) error occured while sending mail.Server reponded: 
| <[e-mail]> is syntactically correct

I cannot reproduce the first error by restarting mozilla or by deleting the 
profile directory.

Comment 21

[leger]

Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.

Comment 22

[(not reading, please use [e-mail] instead)]

ok, I'm able to reproduce this thanks to edwin.

debugging now.

Comment 23

[(not reading, please use [e-mail] instead)]

testing a potential fix...I hope to check this in tonight, marking m16.

Comment 24

[(not reading, please use [e-mail] instead)]

fix in hand, going to get it reviewed now.

Comment 25

[(not reading, please use [e-mail] instead)]

marking fixed.  r=mscott.  sorry this bug was open so long.

Comment 26

[John G. Myers]

The fix violates this directive of section 5.2.10 of RFC 1123.  Reopening.

> Whenever possible, a sender-SMTP SHOULD test only the 
> first digit of the reply code, as specified in Appendix E of RFC-821. 

And why are you looking for both 3xx and 2xx in the same place?  The fix makes no 
sense.

Comment 27

[(not reading, please use [e-mail] instead)]

john, are you saying the problem is that I'm testing for all three digits,
instead of just the first, or are you saying something else?

please elaborate.

dave / edwin:  is the most recent build working for you?

Comment 28

[John G. Myers]

I am saying that the problem isn't fixed, the symptom has just been papered over 
by ignoring out-of-sync replies.  The current code can ignore real failures 
because it is out of sync and doesn't see them.  In this case, the user's 
message would be silently dropped.

I am presuming the only reason the client would get a 2xx to DATA or a 3xx to 
the final "." would be that replies are out of sync.  I unfortunately cannot try 
out the server myself due to iplanet firewall issues.

In addition, both the existing code and the fix violate the specification by 
looking at the second and third digits for no good reason.

Comment 29

[(not reading, please use [e-mail] instead)]

ok, thanks for the additional info.  I'll look into fixing this the right way.

Comment 30

[leger]

Due to slip in schedule, moving this bug from [6/01] to [Will be minus on 6/15] 
for fix deadline.

Comment 31

[(not reading, please use [e-mail] instead)]

moving to m17, since it is not a m16 blocker.

Comment 32

[Jim Roskind]

Cleaning up status whiteboard by marking beta2 minus (we're past 6/15}
It appears that folks are too doomed to handle this for beta2.

What is the market share of servers impacted by this issue?  i.e., How common is 
this problem?  

Adding relnote keyword as well.

Thanks,

Jim

Comment 33

[laurel]

changed relnote to relnote2 so it gets considered/included for beta2 notes. I
may solicit help from someone, maybe mscott?, in pinpointing the wording for a
release note. cc mscott.

Comment 34

[Dave Royal]

Thought I'd try M18. Same error "Alert: Sending of message failed"
I'm now using Linux behind a SOCKS proxy. Same mail server.
Why is this failure so rare? It's a blocker for me!
Dave Royal

Comment 35

[Gervase Markham [:gerv]]

It seems unclear to me whether this bug requires either of a "developer" or 
"user" release note. If anyone feels it does, can they please draft one and then 
nominate with the relnote-user or relnote-rtm strings in the Status Whiteboard.

Thanks :-)

Gerv

Comment 36

[(not reading, please use [e-mail] instead)]

smtp -> jefft

Comment 37

[jefft]

Attachment: A fix

Comment 38

[jefft]

Adding mail3 keyword ...

Comment 39

[scottputterman]

reassigning jefft's bugs to naving

Comment 40

[scottputterman]

marking nsbeta1-.  However, if jefft's patch from 11/13 works, let's take it.

Comment 41

[Péter Bajusz]

Clearing very old milestone (M17) in hope of reevaluation.
Adding "patch" keyword.

Comment 42

[Navin Gupta]

over to the owner

Comment 43

[John G. Myers]

Both the attached patch and the current code fail to address the problem I
mentioned in comment #28.  By accepting 3XX responses to RCPT and 2XX responses
to DATA, Mozilla is failing to detect real errors when replies get out of sync,
leading to potential silent loss of email.

Comment 44

[Wayne Mery (:wsmwk)]

Version 91 has all new smtp backend code. If you can still reproduce this issue, please file a new bug report https://bugzilla.mozilla.org/enter_bug.cgi?product=MailNews%20Core&component=Networking%3A%20SMTP