Unix Programming - Connecting to an SMTP server

Author

Connecting to an SMTP server

chsalvia@gmail.com

2007-04-12, 4:05 am

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?

Logan Shaw

2007-04-12, 4:05 am

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

chsalvia@gmail.com

2007-04-12, 4:05 am

> 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.

Logan Shaw

2007-04-12, 4:05 am

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

William Ahern

2007-04-12, 4:05 am

chsalvia@gmail.com wrote:
>
> 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

, prolonging the
"a ha!" moment for an interminably long time.

[color=darkred]
> 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.

Rainer Weikusat

2007-04-12, 4:05 am

William Ahern <william@wilbur.25thandClement.com> writes:
> chsalvia@gmail.com wrote:
>
> 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?

William Ahern

2007-04-12, 8:05 am

Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> William Ahern <william@wilbur.25thandClement.com> writes:
[color=darkred]
> 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/...5_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.

chsalvia@gmail.com

2007-04-12, 10:03 pm

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.

Logan Shaw

2007-04-12, 10:03 pm

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

Sponsored Links