Remember that a network connection is like a phone call. You don't have to
be on both ends to hear both sides of the conversation. If you put a packet
sniffer on the client, it will hear both sides on the client end. I have
"Mitch" <Mitch@discussions.microsoft.com> wrote in message
news:D18D8235-47AD-4CE5-8B72-4C0709E6B375@microsoft.com...
> Unfortunately, I do not have access to the SMTP server, so I am having to
> deduce all of this from logging information. I do know that the the
> failing
> code is returning
> FALSE from AtlSmtpSendAndCheck(...) which could be returning false from
> calls to either AtlSmtpSendAndWait(...) which uses WriteFile() to write
> "HELO
> [hostname]" to the socket handle or AtlSmtpReadData(...) which uses
> ReadFile() to get the response and check for the "250" code in the first 3
> characters. Since I don't have access to the SMTP server, I was hoping to
> deduce what the problem could be based on the fact that the SmtpMail class
> had no problem at all using the same server.
>
> FYI - When using telnet to check the response to "HELO", the response is
> the
> following ( "xxxxx" for the brand of the proxy & replaced hostnames as
> well ).
>
> 220-xxxxxx SMTP proxy
> 220 a.b.c ESMTP server ready at Thu, 4 May 2006 09:47:35 +0200
> helo myclient
> 250 a.b.c Hello localhost [127.0.0.1], pleased to meet you
>
> The "Hello localhost [127.0.0.1]" jumped out at me since I expected the IP
> address of the calling client. However, that doesn't explain why the
> SMTPMail
> class works.
>
> Sorry I can't provide any better info. Your comments are much
> appreciated!
>
> "Ben Voigt" wrote:
>
>> Every SMTP connection needs to start with either HELO or EHLO (extended
>> HeLOo).
>>
>> But then it's going to possibly start SSL (in which case Ethereal won't
>> help
>> much) and then go on with "MAIL FROM: sender" and "RCPT TO: recipient"
>> (possibly multiple times) then "DATA" followed by the MIME wrapped
>> message
>> and then a period "." on a line by itself which will go back to command
>> mode.
>>
>>
http://cr.yp.to/smtp/mail.html >>
>> "Kevin Spencer" <kevin@DIESPAMMERSDIEtakempis.com> wrote in message
>> news:%23CTMcOHcGHA.1276@TK2MSFTNGP03.phx.gbl...
>> > Can you monitor both sides of the conversation? That is, using Ethereal
>> > (free from Ethereal.com), or some other packet sniffer, check the
>> > entire
>> > conversation, both client and server.
>> >
>> > --
>> > HTH,
>> >
>> > Kevin Spencer
>> > Microsoft MVP
>> > Professional Numbskull
>> >
>> > Hard work is a medication for which
>> > there is no placebo.
>> >
>> > "Mitch" <Mitch@discussions.microsoft.com> wrote in message
>> > news:9A7DFFB0-2D90-48DC-AF97-F3E91A858A19@microsoft.com...
>> >> I've got 2 different applications that use the same SMTP server. One
>> >> is
>> >> written in C# and uses the SmtpMail class. The other is in C++ and
>> >> uses
>> >> the
>> >> ATL CSMTPConnction class. The SmtpMail code works just fine. The
>> >> CSMTPConnection code fails. In digging down into the ATL code, I can
>> >> see
>> >> where it issues a "HELO" command to the smtp server and reads the
>> >> result
>> >> to
>> >> check for a "250" return code as an indicator of success. Using
>> >> telnet,
>> >> I
>> >> can verify that 250 is returned from a "HELO" command. The big
>> >> wrinkle
>> >> here
>> >> is that the smtp server is using a 3rd party smtp security product. I
>> >> suspect that the ATL code is doing something that the 3rd party
>> >> product
>> >> does
>> >> not like. So, finally, my question is about how the SmtpMail class is
>> >> successful. Does the underlying code issue a "HELO" command at all?
>> >>
>> >> TIA - Mitch
>> >
>> >
>>
>>
>>