[beta] Problems sending mail via SMTP

Discussion in 'Windows Live Mail' started by Nick Collingridge, Aug 7, 2010.

  1. I am struggling to get the beta of Windows Live Mail (build 15.3.2804.0607)
    to successfully send mail via my SMTP server. The problem seems to be that
    WLM is not signing on to the server with a FQDN, when the server requires
    that it does.

    As an aside, the server seems to have no problems with hordes of Macs that
    use it for sending mail, or with PCs running Thunderbird, just with this
    Windows 7 system with WLM beta that I am trying to get running to test it.

    The error dialog in WLM says that the server is rejecting the Helo command,
    and it appears that the system name that WLM is sending when logging on is
    just W7SYS (the Computer name that this system has in its system properties).
    I have set the primary DNS suffix to be "domain.com" (where domain.com is the
    domain that the server is expecting to see), and the "Full computer name" as
    reported by System properties is W7SYS.domain.com, but this does not appear
    to be the name that WLM is sending when trying to log on to the server, no
    matter how many times I restart the system (even though this really shouldn't
    be a necessary step).

    What is going wrong here? Is this a bug (a pathetically basic one if so) in
    WLM?
     
    Nick Collingridge, Aug 7, 2010
    #1
    1. Advertisements

  2. So have you tried changing the computer name to domain.com?
    My SMTP server accepts the HELO value 'vaio' (which is my computer's name).

    Gary VanderMolen, Microsoft MVP (Mail)


    "Nick Collingridge" wrote in message
    I am struggling to get the beta of Windows Live Mail (build 15.3.2804.0607)
    to successfully send mail via my SMTP server. The problem seems to be that
    WLM is not signing on to the server with a FQDN, when the server requires
    that it does.

    As an aside, the server seems to have no problems with hordes of Macs that
    use it for sending mail, or with PCs running Thunderbird, just with this
    Windows 7 system with WLM beta that I am trying to get running to test it.

    The error dialog in WLM says that the server is rejecting the Helo command,
    and it appears that the system name that WLM is sending when logging on is
    just W7SYS (the Computer name that this system has in its system properties).
    I have set the primary DNS suffix to be "domain.com" (where domain.com is the
    domain that the server is expecting to see), and the "Full computer name" as
    reported by System properties is W7SYS.domain.com, but this does not appear
    to be the name that WLM is sending when trying to log on to the server, no
    matter how many times I restart the system (even though this really shouldn't
    be a necessary step).

    What is going wrong here? Is this a bug (a pathetically basic one if so) in
    WLM?
     
    Gary VanderMolen, Aug 7, 2010
    #2
    1. Advertisements

  3. Besides the fact that you're not meant to have to do this - the approach I
    took is the proper way of doing it - you also can't do it, as the computer
    name does not permit periods. As things stand I think this must be a glaring
    bug in the WLM beta.

    Any other thoughts?

    Nick
     
    Nick Collingridge, Aug 7, 2010
    #3
  4. As far as I know, the beta is no different in that respect than the previous
    released version, or Windows Mail/Outlook Express for that matter.
    According to Microsoft, the pertinent mail RFCs don't require the HELO
    parameter to be a FQDN.

    I found some old articles about this topic. Perhaps these may help you:

    http://support.microsoft.com/kb/186142
    http://www.linuxmagic.com/best_practices/valid_helo_domain.html#user
    http://www.windowskb.com/Uwe/Forum....QDN-at-SMTP-HELO-EHLO-instead-of-Netbios-name

    Gary VanderMolen, Microsoft MVP (Mail)


    "Nick Collingridge" wrote in message
    Besides the fact that you're not meant to have to do this - the approach I
    took is the proper way of doing it - you also can't do it, as the computer
    name does not permit periods. As things stand I think this must be a glaring
    bug in the WLM beta.

    Any other thoughts?

    Nick
     
    Gary VanderMolen, Aug 7, 2010
    #4
  5. Nick Collingridge

    N. Miller Guest

    Message submission servers should not be requiring FQDNs. The reason for
    that is because many computers are not named using FQDNs. The only mail
    servers which can get away with requiring FQDNs would be MTAs, and you
    should not be connecting directly to an MTA with an email client. So my
    guess would be that the "bug" is with the email service provider not giving
    their customer due regard for the limitations of the customer's email
    clients.
     
    N. Miller, Aug 8, 2010
    #5
  6. After much more research I can see that your explanation is correct as far as
    it goes but it seems like a pathetic reason to me - typical Microsoft of
    course! Just because "many computers are not named using FQDNs" - essentially
    Windows systems, n'est ce que pas? - does not seem a good reason for mail
    servers to not require FQDNs which can then presumably be checked by reverse
    lookup of the domain and validated against spam blockers.

    An alternative would be to provide a decent level of login security by
    implementing authentication at a level above LOGIN which is essentially no
    security at all. But WLM and indeed Outlook and all other MS clients don't do
    so. Whyever not - unless this is an example of antitrust activity in forcing
    people to use Exchange in combination with MS email clients if they want any
    decent level of security? Despicable behaviour if so and entirely
    reprehensible. Good thing there's Thunderbird out there which is getting
    better by the day.

    Another point is that Windows (7 at least) does provide for the computer
    name to have a domain suffix applied to it, leading to what is called the
    "Full Computer Name". So the concept of a FQDN for the computer is built in
    to the OS, but the mail clients refuse to use it. Why not? The name is there,
    ready to be used, so if using it would help with compatibility of the client
    with loads of email servers out there, why not do so? Unless we once again
    get back to MS trying to protect their position in the market by childish and
    underhand means. What are they so scared of? Why not try and make WLM the
    best and most compatible email client it could be, instead of a weaker
    offering than the (developed in people's spare time) competition as it
    appears that it is?
     
    Nick Collingridge, Aug 9, 2010
    #6
  7. Nick Collingridge

    N. Miller Guest

    The reverse lookup of my 'domain' (which is 'pacbell.net') would only
    indicate that it is from a block of dynamically assigned IP addresses; which
    are also /persona non grata/ for many MTAs. Essentially, a message
    submission server is a special type of email server which exists so the user
    of an email service can submit email into the email system. There are better
    methods of authenticating users to a message submission server than rDNS
    lookups.
    Probably would require a complete overhaul of the SMTP system, which would
    obsolete a lot more email clients than just MS email clients. Not to mention
    all of the servers (Exhchange is only popular with enterprises tied to MS;
    Unix-based mail servers are probably more prevalent on the Internet).
    Probably a legacy of an earlier time. Mozilla Thunderbird does not use the
    computer name at all, it uses the computer IP address; which is an RFC 1918
    reserved private use IP address in many cases. And most MTAs which refuse
    FQDNs probably also refuse RFC 1918 IP addresses from Internet connections.
    I know mine does.
    That is backwards. It is the mail servers which should be compatible with
    legacy email clients.
    They leveraged the code of a legacy email client (MS Outlook Express), for a
    free product (Windows Live Mail). MS Outlook Express is not the only legacy
    email client which is "incompatible" with the way some message submission
    server administrators have misconfigured their servers. Here is part of what
    Mozilla Thunderbird sends:

    | Received: from [192.168.102.34] (adsl-68-125-49-147.dsl.pltn13.pacbell.net [68.125.49.147])

    I draw your attention to three problems:

    1.) Computer name is an RFC 1918 IP address.
    2.) Reverse DNS name indicates a dynamic IP address block.
    3.) IP address is dynamically assigned.

    All three are red flags for MTAs, and should result in a rejection from an
    MTA. All three are a consequence of legacy code in the email client (Mozilla
    has done it that way since Netscape Navigator 3.0), or ISP convention (ATTIS
    is just continuing what Pacific Bell started doing for their Internet
    customers years ago).

    None of them should be used by a message submission server to authenticate
    the user (with the exception that ATTIS could use an ACL to allow incoming
    connections from only their own IP addresses; but that is really a clunky
    way of doing things). In this particular case, AOL, which operates the
    message submission server for its users of accounts in the 'aim.com' and
    'netscape.net' domains, requires authentication using TLS over port 587 for
    the message submission. Windows Live Mail actually handles that very well
    (i.e., I am able to send email through 'smtp.aim.com:587' w/TLS using
    Windows Live Mail to connect with the AOL message submission server). The
    AOL message submission server does not care what the SMTP EHLO string
    contains, only that the TLS Username+Password is in their system.
    Why not configure the message submission server properly in the first place?
    Use port 465 with SSL, or port 587 with TLS, and the server shouldn't care
    what the client reports in the SMTP EHLO string.
     
    N. Miller, Aug 9, 2010
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.