Connecting to an SMTP server - Unix

This is a discussion on Connecting to an SMTP server - Unix ; I'm trying to write basic C program which connects to an SMTP server. I use google's mail server (64.233.185.114) as a test. Using a simple connect() function call, I do: int port = 25; memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Connecting to an SMTP server

  1. Connecting to an SMTP server

    I'm trying to write basic C program which connects to an SMTP server.
    I use google's mail server (64.233.185.114) as a test.

    Using a simple connect() function call, I do:

    int port = 25;
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_port = htons(port);
    memcpy(&addr.sin_addr, &serv_addr, sizeof(serv_addr));

    if (::connect(sock, (sockaddr*) &addr, sizeof(addr)) == -1) {
    if (errno == EINPROGRESS) {
    switch(select_wr(conn_timeout)) {
    case 0: return false;
    case -1: return false;
    default: break;
    }
    }
    }

    But it simply hangs. However, an HTTP connection on port 80 to www.gmail.com
    works fine. I also tried using a simple telnet connection on the
    console, like

    telnet 64.233.185.114

    ....but this also hangs. I tried this on two different ISPs, just to
    make sure my ISP wasn't blocking port 25. But it always hangs. Am I
    missing a step? What are some reasons why this might not work? Could
    it be the OS (Linux ubuntu) is blocking port 25 for some reason?


  2. Re: Connecting to an SMTP server

    chsalvia@gmail.com wrote:
    > I'm trying to write basic C program which connects to an SMTP server.
    > I use google's mail server (64.233.185.114) as a test.


    > But it simply hangs. However, an HTTP connection on port 80 to www.gmail.com
    > works fine. I also tried using a simple telnet connection on the
    > console, like
    >
    > telnet 64.233.185.114


    You mean like this?

    telnet 64.233.185.114 25

    > ...but this also hangs. I tried this on two different ISPs, just to
    > make sure my ISP wasn't blocking port 25.


    A *lot* of ISPs block port 25 because of the thousands (or maybe
    millions, who knows) of zombie-infested computers sending billions
    of spam messages. Are you sure that both the ISPs you tried aren't
    blocking the port?

    I would try connecting to the SMTP server that your ISP supplies.
    They will probably let you connect to that. I'd try with 'telnet'
    first, since that's easier.

    - Logan

  3. Re: Connecting to an SMTP server

    > A *lot* of ISPs block port 25 because of the thousands (or maybe
    > millions, who knows) of zombie-infested computers sending billions
    > of spam messages. Are you sure that both the ISPs you tried aren't
    > blocking the port?


    It's certainly plausible. I'll have to check into that.

    > I would try connecting to the SMTP server that your ISP supplies.
    > They will probably let you connect to that. I'd try with 'telnet'
    > first, since that's easier.


    Thanks for the suggestion. So far, the email program I've written is
    limited to simply looking up MX records from DNS servers. But I
    wonder exactly how one email server actually sends messages to another
    email server. The reason I wonder this is because I've noticed that
    various email servers use different ports and/or protocols (POP3,
    IMAP, etc.). So how does one email server know which port/protocol to
    use when sending to another email server? For example, it seems gmail
    uses POP3 on port 995, while something like Yahoo might use another
    port. How would gmail know which port to use when sending to Yahoo,
    since this information is not provided in the DNS MX record? Is it
    simply a matter of guessing/retrying? Also, some email servers use
    SSL encryption, while others don't. Again, there seems to be no way
    to determine whether or not a server uses SSL beforehand (unlike
    something like HTTP, which gives the obvious HTTPS indicator.) So how
    is all this information determined, to make email server-to-server
    communication possible?

    Any information you can give me regarding this would be extremely
    appreciated.

    Thanks.



  4. Re: Connecting to an SMTP server

    chsalvia@gmail.com wrote:
    > Thanks for the suggestion. So far, the email program I've written is
    > limited to simply looking up MX records from DNS servers. But I
    > wonder exactly how one email server actually sends messages to another
    > email server. The reason I wonder this is because I've noticed that
    > various email servers use different ports and/or protocols (POP3,
    > IMAP, etc.). So how does one email server know which port/protocol to
    > use when sending to another email server?


    Good question.

    Actually, the job for a mail server is quite simple. Mail servers
    always use SMTP protocol over port 25. (Well, older ones used
    various other transports, like sending mail over UUCP, but I'm
    talking about typical, modern mail servers here.)

    POP3 and IMAP are never used between two servers, only between a
    client and a server. It might be a little bit of an oversimplification,
    but you can think of SMTP as a "push" protocol (message sender initiates
    connection) and POP3 and IMAP as "pull" protocols (message recipient
    initiates connection). That's why only SMTP makes sense for server
    to server communication.

    > For example, it seems gmail
    > uses POP3 on port 995, while something like Yahoo might use another
    > port.


    Yes, there is indeed a lot of variation in ports used for POP3 and
    IMAP. Basically, though, this is considered a "private" matter in
    a sense, because it's always between a client and a server. The
    client and server are presumed to be run by the same party or by
    two related parties who have other means of communications to
    settle on a port number, and on other things like mail server
    hostnames.

    The mail reason there are two ports for IMAP and two for POP3 is
    that one is typically used for encrypted and one for unencrypted
    communications.

    > Also, some email servers use
    > SSL encryption, while others don't. Again, there seems to be no way
    > to determine whether or not a server uses SSL beforehand (unlike
    > something like HTTP, which gives the obvious HTTPS indicator.)


    Yes, that's right, mail servers do use encryption sometimes and
    sometimes not. There is indeed no indication before the TCP
    connection is established which it's going to be.

    So, the encryption is handled by negotiation. After the TCP
    connection is established, the initiator of the connection can
    send a "EHLO" command identifying itself. This is like the older
    "HELO" ("hello") command, but "EHLO" also allows the remote mail
    server to send back a list of protocol extensions it supports.
    If it supports TLS (the successor to SSL) encryption, it will
    send back a "250-STARTTLS" line in the response. If the other
    side (the side that asked about capabilities in the first place)
    also supports it and wants to use it, it will then issue a
    "STARTTLS" command. At that point, the encryption starts.

    You can find out more information about that by googling for
    something like 'starttls smtp' or 'starttls ehlo'.

    Now, to complicate matters a little, you may have noticed that
    sometimes servers speak SMTP on two different ports: 25 and 587.
    Instead of having one port for encrypted and one port for plain
    text, like HTTP, IMAP, and POP3 all do, the separation between
    ports has a different purpose. Both 25 and 587 can support
    encryption. The difference is that port 25 is used for server
    to server transfer of messages, and port 587 is used when a
    client wants to submit a message to a mail server to be
    sent on to some other mail server. It seems a little redundant
    to have both, but the purpose is simply that messages coming in
    on port 25 (server-to-server messages) can be held to a
    different standard than those coming in on port 587 (local
    messages). You could, for example, do no spam filtering on
    port 587. Or you could require encryption and authentication
    on port 587 and thus forces all your clients to use both
    encryption and authentication. Plus, you can apply looser
    standards to how messages are formatted (missing headers, etc.)
    if they come in on port 587, whereas a real mail server is
    expected to get the formatting right and have inserted all
    the proper headers.

    - Logan

  5. Re: Connecting to an SMTP server

    chsalvia@gmail.com wrote:
    > > A *lot* of ISPs block port 25 because of the thousands (or maybe
    > > millions, who knows) of zombie-infested computers sending billions
    > > of spam messages. Are you sure that both the ISPs you tried aren't
    > > blocking the port?

    >
    > It's certainly plausible. I'll have to check into that.


    Likely more than plausible. I'd stop just short of _common_.

    What's maddening though, is that too often they drop port 25 bound packets,
    rather than reject them. This generally leaves one confused, prolonging the
    "a ha!" moment for an interminably long time.

    > > I would try connecting to the SMTP server that your ISP supplies.
    > > They will probably let you connect to that. I'd try with 'telnet'
    > > first, since that's easier.


    > Thanks for the suggestion. So far, the email program I've written is
    > limited to simply looking up MX records from DNS servers. But I
    > wonder exactly how one email server actually sends messages to another
    > email server. The reason I wonder this is because I've noticed that
    > various email servers use different ports and/or protocols (POP3,
    > IMAP, etc.). So how does one email server know which port/protocol to
    > use when sending to another email server? For example, it seems gmail
    > uses POP3 on port 995, while something like Yahoo might use another
    > port. How would gmail know which port to use when sending to Yahoo,
    > since this information is not provided in the DNS MX record? Is it
    > simply a matter of guessing/retrying? Also, some email servers use
    > SSL encryption, while others don't. Again, there seems to be no way
    > to determine whether or not a server uses SSL beforehand (unlike
    > something like HTTP, which gives the obvious HTTPS indicator.) So how
    > is all this information determined, to make email server-to-server
    > communication possible?


    Its not. The process is much more simple than that. Mail is exchanged using
    SMTP over port 25. POP3+ and IMAP provide methods for sending mail upstream
    to servers, but that's for end users and end users' client software; its not
    how servers talk to each other. TLS can be negotiated from an established
    SMTP connection using the ESMTP framework. Google, and Wikipedia in
    particular, will have more information.


  6. Re: Connecting to an SMTP server

    William Ahern writes:
    > chsalvia@gmail.com wrote:
    >> > A *lot* of ISPs block port 25 because of the thousands (or maybe
    >> > millions, who knows) of zombie-infested computers sending billions
    >> > of spam messages. Are you sure that both the ISPs you tried aren't
    >> > blocking the port?

    >>
    >> It's certainly plausible. I'll have to check into that.

    >
    > Likely more than plausible. I'd stop just short of _common_.


    Can you provide a list of ISP that drop packets of their customers
    based on certain 16-bit quantities in a TCP-header?

  7. Re: Connecting to an SMTP server

    Rainer Weikusat wrote:
    > William Ahern writes:
    > > chsalvia@gmail.com wrote:
    > >> > A *lot* of ISPs block port 25 because of the thousands (or maybe
    > >> > millions, who knows) of zombie-infested computers sending billions
    > >> > of spam messages. Are you sure that both the ISPs you tried aren't
    > >> > blocking the port?
    > >>
    > >> It's certainly plausible. I'll have to check into that.

    > >
    > > Likely more than plausible. I'd stop just short of _common_.


    > Can you provide a list of ISP that drop packets of their customers
    > based on certain 16-bit quantities in a TCP-header?


    I suppose I should have qualified that remark by mentioning I was assuming
    the OP was on a residential network, which, granted, is a big assumption.
    Here's a link, and I'll let you do your own research hereafter:

    http://www.postcastserver.com/help/P..._Blocking.aspx

    AT&T, MindSpring, BellSouth, MSN, CableOne, NetZero, Charter, People
    PC, Comcast ATTBI, Sprynet, Cox, Sympatico.ca, EarthLink, Verio,
    Flashnet Verizon, MediaOne

    However, when blocking port 25 was a bona fide fad in the US (the idea
    spread like wildfire a few years ago), I did manage a network w/ a
    *commercial* leased line where the provider blocked port 25 globally, then
    lifted it for those who complained. So, this issue is (or at least was at
    the time) not strictly confined to residential lines.

  8. Re: Connecting to an SMTP server

    Logan,

    Thanks for all the information. You've been extremely helpful. I had
    originally supposed that SMTP server-to-server communication was
    always done through port 25, but when that didn't seem to work, I
    thought I was doing something wrong. As it turns out, you're right -
    my ISP does block port 25. I tried another ISP meant for business
    connections, and it worked fine.

    Again, thanks for all the info.



  9. Re: Connecting to an SMTP server

    William Ahern wrote:
    > However, when blocking port 25 was a bona fide fad in the US (the idea
    > spread like wildfire a few years ago), I did manage a network w/ a
    > *commercial* leased line where the provider blocked port 25 globally, then
    > lifted it for those who complained. So, this issue is (or at least was at
    > the time) not strictly confined to residential lines.


    I would have no problem at all with this idea were it to only apply to
    new accounts. That is, if they leave existing accounts alone, and leave
    port 25 blocked by default for all new accounts (unless you ask to have
    it unblocked while setting up the account), and if they were to never
    screw it up :-), that would work just fine for my tastes.

    - Logan

+ Reply to Thread