Timing out with EMail server

[Controls Guy]

I'm trying to send an email but the connection keeps timing out after reaching the point where it says "SMTP connected!", as if the SMTP server isn't acknowledging the DM's logon attempt, but I've tried every option I can think of in the SMTP device config and have tried to replicate the settings in an email client that is working fine.  I've attached a screenshot of my DML log of a couple attempts to send one.

[franji1]

What is the duration of the manual session?  10 seconds?  60 seconds?  120 seconds?  Not sure what the default timeout is for Do-more (but you can adjust it).  It needs to be pretty high so you don't get any false timeouts reported.

Make sure the Do-more CPU's subnet mask and its gateway address are consistent with the Do-more's IP Address (assuming your SMTP server is not on your local subnet).

[Controls Guy]

When I get a sec I'll Wireshark some transactions from TBird.   I also have one of those mirroring switches so I can do a more detailed capture of the Do-More's login attempts.  Then we can dissect those.

[Controls Guy]

We cross-posted.  The timeout for that log was 5 seconds, but I tried as high as 30 seconds, which is far longer than that server typically requires to respond.   Subnet and gateway are the same as the working client,  plus as you see, it completes a connection to the server to its satisfaction so it must be able to reach it.   I'll get some detailed captures and we can look at those.

[MikeS]

one of the first things i'd try is using a different SMTP server. if you can get to it, Google has one that we use, it's at aspmx.l.google.com. Do a DNSLookup of that name to get the current IP address (they've been known to change it occasionally). Then use that IP address for the SMTP server and send yourself a test email.

if that works then it definitely means the first SMTP server is where the problem lies.

While you are doing that i'll research what we're sending and expecting to receive right after we get the "SMTP Connected!" message.

[Controls Guy]

if that works then it definitely means the first SMTP server is where the problem lies.

That doesn't follow.  If ANY SMTP server reacts differently to Do-More than it does to another client, that means it can tell which is which.  It can only tell which is which if Do-More and the other client are doing something differently. Doesn't necessarily mean that Do-More is the one doing it wrong, but it does mean that it's different than the email client software.

[MikeS]

at the point its failing for you, the TCP connection on port 25 has been established, and we're waiting on the SMTP server to say it's ok for the client to begin.

So at this point the SMTP server doesn't know what type of client it's talking to, it has simply accepted a connection from a client. Do-more's SMTP client hasn't even sent the "HELO" which initiates the actual email work.

[BobO]

I'm told that the ECOM100 treats the initial greeting as optional, although Do-more does not. I haven't spoken to the ECOM100 firmware guy about it yet, so I don't know his reasoning, but the spec is pretty clear on the issue. From RFC 5321:

"4.3.1. Sequencing Overview

   The communication between the sender and receiver is an alternating
   dialogue, controlled by the sender.  As such, the sender issues a
   command and the receiver responds with a reply.  Unless other
   arrangements are negotiated through service extensions, the sender
   MUST wait for this response before sending further commands.  One
   important reply is the connection greeting.  Normally, a receiver
   will send a 220 "Service ready" reply when the connection is
   completed.  The sender SHOULD wait for this greeting message before
   sending any commands."

Bolding and italics are mine, but the caps are in the spec.

[Controls Guy]

So at this point the SMTP server doesn't know what type of client it's talking to, it has simply accepted a connection from a client.

There by definition has to be a difference or the results would be the same.  That seems self-evident.  It may very well be that the SMTP server is doing something non-spec and the email client has been written to accept it.  In turn, that raises the issue that if that particular non-spec behavior is common enough that people are writing their email clients to tolerate it, then perhaps Do-More should as well, or at least allow it as a configuration option.  It's also entirely likely that I haven't managed to configure Do-More's authentication options to reproduce what Thunderbird does, and that's the reason for the difference, but rest assured, there has to be a difference.

As I said yesterday, I'll Wireshark the email program and do the same with the Do-More and that will tell us more about whatever may be different.

[ADC Product Engineer]

One other important thing to note is that there is an extension of the SMTP spec (RFC 1820) where the greeting starts with ELHO instead of HELO.  It is possible that the server is set to only respond to the ELHO command, instead of both HELO and ELHO.

[BobO]

I'd give it nearly 100% than the server isn't issuing a greeting upon connection. The fact that Don supported that with the ECOM100 is indicative of there being some popular support for such, but, it is awkward at best. Dang near exactly like when you call someone and they don't say "Hello" or your cell phone broke up when they did. The ensuing "Hello...Hello...you there?" is painful with two humans, and similarly so to codify.

We have been shipping for over 2 years and this is the first I've heard of it, so I'm guessing that it isn't that common a problem. Even so, I would happily fix it...if I weren't eyeballs deep in new platform development.

[BobO]

One other important thing to note is that there is an extension of the SMTP spec (RFC 1820) where the greeting starts with ELHO instead of HELO.  It is possible that the server is set to only respond to the ELHO command, instead of both HELO and ELHO.

I doubt it. The problem is before the HELO.

[Controls Guy]

OK, think I got to the bottom of it.

• Email server POP/SMTP is doing something unusual or unanticipated by Do-More
  
• Email clients are written to accommodate the behavior (don't know how common it is).

Since nothing else was working I suspected that the correct authentication might possibly be POP before SMTP because TBird automagically checks for email upon startup, so by the time you want to send an email, your IP address will have already been authenticated from the server's point of view.

I changed to POP-before-SMTP mode, and Do-More will then complete a successful authentication with the POP server.  Problem IS.....the POP and SMTP servers have different URLs, and while TBird allows for that, Do-More does not.  Again I have no idea how common this is, but allowing for separate POP and SMTP URL's might be something you'd want to consider adding if it's easy and if anyone else runs into this issue.  Meantime I'll find an email server that doesn't have that issue.

Thanks!

[BobO]

It doesn't sound unusual at all. POP before SMTP is common, and apparently the SMTP server is simply refusing to greet when he hasn't first been alerted to the pending SMTP request via POP. That wouldn't be my preferred handling (error code would be better) but I can't say it is wrong.

When you say different URL, what do you mean? Different IP address between POP and SMTP?

[Controls Guy]

Yes!   POP is pop.myisp.com with one IP,  and SMTP is smtp.myisp.com with a different IP.