No SSL on fetchmail?

How does one turn off SSL on fetchmail, or is that possible?

Longfellow

Re: No SSL on fetchmail?

Longfellow wrote:
> How does one turn off SSL on fetchmail, or is that possible?
>

It depends on the port you connect to.

From man fetchmail:


--ssl (Keyword: ssl) Causes the connection to the mail server to be
encrypted via SSL. Connect to the server using the specified base
protocol over a connection secured by SSL. SSL support must be present
at the server. If no port is specified, the connection is attempted
to the well known port of the SSL version of the base protocol. This is
generally a different port than the port used by the base protocol.
For IMAP, this is port 143 for the clear protocol and port 993 for the
SSL secured protocol.


So, if you want to use fetchmail on an IMAP server without using SSL,
then have it connect to the server using port 143, or to port 110 for POP3.

I'd recommend that you continue to use SSL if your server supports it,
else you'll be sending your login username and password over an insecure
link each time fetchmail connects to the server.

--
Garen

Re: No SSL on fetchmail?

On 2007-03-30, Garen Erdoisa wrote:
> Longfellow wrote:
>> How does one turn off SSL on fetchmail, or is that possible?
>>
>
> It depends on the port you connect to.
>
> From man fetchmail:
>
>
> --ssl (Keyword: ssl) Causes the connection to the mail server to be
> encrypted via SSL. Connect to the server using the specified base
> protocol over a connection secured by SSL. SSL support must be present
> at the server. If no port is specified, the connection is attempted
> to the well known port of the SSL version of the base protocol. This is
> generally a different port than the port used by the base protocol.
> For IMAP, this is port 143 for the clear protocol and port 993 for the
> SSL secured protocol.
>
>
> So, if you want to use fetchmail on an IMAP server without using SSL,
> then have it connect to the server using port 143, or to port 110 for POP3.
>
> I'd recommend that you continue to use SSL if your server supports it,
> else you'll be sending your login username and password over an insecure
> link each time fetchmail connects to the server.

Aha, that clarifies things. SSL with POP3 connects to a different port
than 110, then?

My ISP just upgraded their pop3 server software, causing interesting
stuff with windows machines, and causing no connectability for me. So I
called them up and they told be "click on..." at which point I told them
I wasn't running windows (dead silence). Finally the guy said that the
new software didn't support SSL. I asked him when that support would be
avaiable and he told me it would not be available, period.

So I reedited .muttrc to download and got mail that way (lots of hand
moving to different mailboxes... arggh) and a .muttrc1 for the second
mail box (#$%%^&). The I telneted into 110 and checked STAT for each
mailbox, and I'd gotten it all. So I killed the fetchmail daemon and
tried to figure out where to go from there. Wound up posting here.

On a hunch, I fired up the fetchmail daemon and turned out the light,
figuring come what may. Hours later, I sat down and turned on the
light, monitor came up and lo and behold, there was mail in all boxes!

I'm going to stop by the ISP today and ask what is going on. I think
the tech guy just didn't know what he was talking about, or maybe they
got enough complaints that they "did something".

I've got aDSL 24/7 to the ISP. The guy intimated that if there was a
packet sniffer, it would be on my own LAN (???), apparently implying
that nothing of the sort would be possible between my gateway and the
ISP. Don't know what's going on, but hope to find out.

Thanks,

Longfellow

Re: No SSL on fetchmail?

Longfellow wrote:
> On 2007-03-30, Garen Erdoisa wrote:
>> Longfellow wrote:
>>> How does one turn off SSL on fetchmail, or is that possible?
>>>
>> It depends on the port you connect to.
>>
>> From man fetchmail:
>>
>>
>> --ssl (Keyword: ssl) Causes the connection to the mail server to be
>> encrypted via SSL. Connect to the server using the specified base
>> protocol over a connection secured by SSL. SSL support must be present
>> at the server. If no port is specified, the connection is attempted
>> to the well known port of the SSL version of the base protocol. This is
>> generally a different port than the port used by the base protocol.
>> For IMAP, this is port 143 for the clear protocol and port 993 for the
>> SSL secured protocol.
>>
>>
>> So, if you want to use fetchmail on an IMAP server without using SSL,
>> then have it connect to the server using port 143, or to port 110 for POP3.
>>
>> I'd recommend that you continue to use SSL if your server supports it,
>> else you'll be sending your login username and password over an insecure
>> link each time fetchmail connects to the server.
>
> Aha, that clarifies things. SSL with POP3 connects to a different port
> than 110, then?

Yes, pop3s uses port 995.

grep pop3 /etc/services
pop3 110/tcp pop-3 # POP version 3
pop3 110/udp pop-3
pop3s 995/tcp # POP-3 over SSL
pop3s 995/udp # POP-3 over SSL

>
> My ISP just upgraded their pop3 server software, causing interesting
> stuff with windows machines, and causing no connectability for me. So I
> called them up and they told be "click on..." at which point I told them
> I wasn't running windows (dead silence). Finally the guy said that the
> new software didn't support SSL. I asked him when that support would be
> avaiable and he told me it would not be available, period.

I suspect the software they are using does support SSL, they just don't
know how to configure it properly. Configuring SSL for the server is
desirable (if you wish to avoid seeing lots of warning messages in the
server logs). This means you have to setup SSL server certificates for
the pop3 and imap servers which are signed by a trusted certificate
authority.

I think that just about any competent email admin can become proficient
at doing this with a couple of weeks of study.

>
> So I reedited .muttrc to download and got mail that way (lots of hand
> moving to different mailboxes... arggh) and a .muttrc1 for the second
> mail box (#$%%^&). The I telneted into 110 and checked STAT for each
> mailbox, and I'd gotten it all. So I killed the fetchmail daemon and
> tried to figure out where to go from there. Wound up posting here.
>
> On a hunch, I fired up the fetchmail daemon and turned out the light,
> figuring come what may. Hours later, I sat down and turned on the
> light, monitor came up and lo and behold, there was mail in all boxes!

Quite often such server software will come with a default server
certificate configured for localhost use. This should allow SSL sessions
to run, abet with warning messages in the logs that the certificate name
doesn't match the hostname. Until a genuine certificate is generated for
the server with a certificate name that does match the hostname, those
warning messages will continue. I've run into the same situation with
one of my ISP's. Admins there too lazy or clueless to want to support
SSL by generating proper certificate for it, even though the canned
software they use allows for it's use, and is running with the canned
server certificate. Fetchmail complains about it in the logs, but it
still runs ok.

>
> I'm going to stop by the ISP today and ask what is going on. I think
> the tech guy just didn't know what he was talking about, or maybe they
> got enough complaints that they "did something".
>

Suggest to your tech support guy that they take a look at the SSL
documentation on the apache website. Much of that information that
pertains to using web certificates for secure web sites also pertains to
using similar SSL certificates for email servers, pop, and imap servers.
It didn't take me all that long to configure SSL certificates for my own
servers even back when I first started using SSL. Now day's it's a
simple matter, less than an hours work to update the certificates once a
year just before they expire. Just have to remember to do it. heh.

IMHO anyone running email or web servers should become familiar with
using SSL. It's just part of the job.

Here's a link to a good intro on the subject.

http://httpd.apache.org/docs/2.0/ssl/ssl_intro.html

> I've got aDSL 24/7 to the ISP. The guy intimated that if there was a
> packet sniffer, it would be on my own LAN (???), apparently implying
> that nothing of the sort would be possible between my gateway and the
> ISP. Don't know what's going on, but hope to find out.

He may be right at least in part. DSL lines are carried over the
telephone networks and are linked directly to a DSLAM server generally.
Short of putting a wire tap on the phone line being used (which I
believe is illegal without a court order), the DSL line should be just a
point to point link from your DSL modem to their gateway server. Any
packet sniffing done on your physical line would only pick up traffic
between their gateway and your DSL modem. If you are connecting to your
ISP's pop3 server and not using SSL, then it's marginally safer than
poping mail down from a different non-local ESP such as hotmail. For
such remote ESP's you should be using SSL if they support it since you
have no idea really where the packets are being routed between you and them.

--
Garen