First let me correct myself the people that I had Relay For worked. Anyone that used SMTP AUTH did not work. There was no entries in the log file stating failed SMTP AUTH sessions, it was like they were not even hitting my server. It would keep asking the client over and over to enter their password to send mail. I restarted my SMTP service and they were able to send mail, and I seen the SMTP AUTH sessions authenticate in the log file. Maybe it was just a glitch, I don't know but it is working now.
Before I got to work: 20021029 074545 127.0.0.1 SMTPD (99A0014C) [65.66.8.21] connect 24.116.28.216 port 1058 20021029 074546 127.0.0.1 SMTPD (99A0014C) [24.116.28.216] HELO prod 20021029 074546 127.0.0.1 SMTPD (99A0014C) [24.116.28.216] MAIL FROM: <[EMAIL PROTECTED]> 20021029 074546 127.0.0.1 SMTPD (99A0014C) [24.116.28.216] RCPT TO: <[EMAIL PROTECTED]> 20021029 074546 127.0.0.1 SMTPD (99A0014C) [24.116.28.216] ERR mail.compworldnet.com invalid user <[EMAIL PROTECTED] Once I restarted the SMTP service: 20021029 093149 127.0.0.1 SMTPD (1B480224) [65.66.8.21] connect 24.116.28.216 port 1321 20021029 093149 127.0.0.1 SMTPD (1B480224) [24.116.28.216] EHLO prod 20021029 093149 127.0.0.1 SMTPD (00000CDC) Authenticated [EMAIL PROTECTED], session treated as local. 20021029 093150 127.0.0.1 SMTPD (1B480224) [24.116.28.216] MAIL FROM: <[EMAIL PROTECTED]> 20021029 093150 127.0.0.1 SMTPD (1B480224) [24.116.28.216] RCPT TO: <[EMAIL PROTECTED]> 20021029 093150 127.0.0.1 SMTPD (1B480224) [24.116.28.216] C:\IMail\spool\Da9e6224.SMD 3464 20021029 093150 127.0.0.1 SMTPD (1B480224) [24.116.28.216] MAIL FROM: <[EMAIL PROTECTED]> 20021029 093150 127.0.0.1 SMTPD (1B480224) [24.116.28.216] RCPT TO: <[EMAIL PROTECTED]> 20021029 093150 127.0.0.1 SMTP (972) processing C:\IMail\spool\Qa9e6224.SMD 20021029 093150 127.0.0.1 SMTP (972) Trying VANOSS.K12.OK.US (0) 20021029 093150 127.0.0.1 SMTP (972) Connect VANOSS.K12.OK.US [156.110.12.72:25] (1) 20021029 093150 127.0.0.1 SMTP (972) 220 dash.onenet.net -- Server ESMTP (iPlanet Messaging Server 5.2 HotFix 1.01 (built Sep 10 2002)) 20021029 093150 127.0.0.1 SMTP (972) >EHLO mail.compworldnet.com 20021029 093150 127.0.0.1 SMTPD (1B480224) [24.116.28.216] C:\IMail\spool\Da9e3224.SMD 1693 Thanks, Kris McElroy [EMAIL PROTECTED] Internet Systems Engineer Duracom, INC. www.duracom.net ----- Original Message ----- From: "Sanford Whiteman" <[EMAIL PROTECTED]> To: "Len Conrad" <[EMAIL PROTECTED]> Sent: Tuesday, October 29, 2002 11:35 PM Subject: Re[3]: [IMail Forum] SMTP PROBLEMS > > come on, Sandy, you know when SMTP AUTH fails, works, fails, and > > then just works forever, NOBODY knows how to fix it. > > Sho' nuff, *if SMTP AUTH is what is failing*. Like I said-- > > >> When I refer to the logs "indicating" this issue, I mean they must > >> "reflect" or "establish" that there is an issue... > > --so if he's seeing SMTP AUTH failures, there will be evidence be in > the logs: either because AUTH-attempting sessions, and only > AUTH-attempting sessions, will not close properly (which would > readable from the logs), or because 'failed authentication' will be > logged outright. Note that, as of his post, Kris thought there were > two affected groups: > > > the clients that I have set to use SMTP AUTH or Relay for. > > In other words, there's no reason, without looking at the logs, to > presuppose that the former group (relay by AUTH) is having the > problems you mention, but the latter group (relay by IP) is actually > not seeing what he thinks it's seeing. Kris also never wrote back to > clarify whether, indeed, he was saying that (a) everyone who's > supposed to relay can't relay, (b) everyone who's supposed to relay > can't send at all, or (c) something else. So our discussion could be > completely off-base from the poster's situation, anyway. > > > 1) the SMTP session hangs after the SMTP AUTH string is sent from > > the mail client and Imail passes the string to a new SMTPD pid to do > > the AUTH. The new PID never returns and answer, the main STMPD > > sessions stalls cold. > > It doesn't happen this way. The AUTH happens in the same thread as the > EHLO by calling a function in a DLL: no new thread or new PID. So it's > either the calling routine or the AUTH function in the support DLL > that you're pointing to, and there (see below) it's no sure thing that > the function is receiving the correct data, since it's no sure thing > that the caller is receiving the correct data. Of course, it should > not hang on failure. > > > 2) at the same point, the SMTPD PID comes back saying "auth failed", > > while the user and password are very clearly valid. > > I would have to see whether, on the wire, the user and password are > "very clearly valid," then whether they are passed correctly to the > AUTH function, before blaming the AUTH function. (The creds can be > difficult to validate, since everything is hashed, but it's important > to be scientific.) > > -Sandy > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
