Settings for Eudora 7 for using a smarthost
Alfred Molon
Eudora 7 to use a smarthost?
--
Alfred Molon
http://www.molon.de - Photos of Asia, Africa and Europe
John H Meyers
> Can anybody explain or post a link to a page explaining
> how to set up Eudora 7 to use a smarthost?
A "smarthost," as the term is conventionally used,
is just an SMTP server (although it often means
a "forwarding" server used by another SMTP server).
Eudora uses whatever SMTP server(s) you tell it to use, per personality.
If you give an example of what you are trying to accomplish,
perhaps the details for accomplishing it can then better be discussed.
http://en.wikipedia.org/wiki/Smart_host
--
John H Meyers
Personality "A" receives POP mail for domain "A,"
but wants to send mail via an unrelated SMTP server
which requires "authentication,"
via a different username/password than POP server "A."
Solution:
Set up personality "B" with the alternate SMTP server info,
including its username/password for authentication.
Choose personality "B" as the "SMTP relay personality"
in the main "Sending mail" settings.
Mark "Use relay personality" in personality "A"s "properties"
(right click "A" in the "Personalities" window and choose "Properties")
Now when you send mail for the "A" personality,
it will use the alternate SMTP server and username/password/etc.
--
Alfred Molon
I've sent email with Eudora 7 while the computer was connected to the
Internet through a mobile phone (using GSM mobile data services). The
email bounced back, because the recipient was using a
barracudacentral.com service which identified the IP address of my
mobile phone provider as having a poor reputation.
I posted the problem to the German newsgroup about mobile communications
and somebody suggested to use a "smarthost".
I asked my webspace provider and they said that my SMTP server is
already a smarthost and that I just need to set up the email software
accordingly. Apparently I have to authenticate myself before sending
emails.
What I don't know is if I have set up Eudora properly. In any case, the
purpose of the exercise is to reduce the number of sent emails which are
blocked by spam filters.
Sometimes I have the impression that when I am using a WLAN hotspot or
GSM mobile data services to send emails, the emails do not arrive. I
also have the impression that WLAN hotspots exchange the SMTP servers: I
specify the SMTP server of my host, but perhaps the WLAN service changes
that to the SMTP server of the WLAN provider.
I also remember that in one case, while I was travelling in France last
month, I was unable to send emails through the WLAN hotspot of a hotel.
No idea if this was caused by the firewall of the internet service of
the hotel or by something else.
In any case, the general problem is sending emails while travelling.
Sometimes I'm unable to send emails (but I can receive them and surf the
web) and sometimes the emails are blocked by some spam filter.
John H Meyers
> I've sent email with Eudora 7 while the computer was connected to the
> Internet through a mobile phone (using GSM mobile data services).
> The email bounced back, because the recipient was using a
> barracudacentral.com service which identified the IP address
> of my mobile phone provider as having a poor reputation.
If you did not make any adjustment to your Eudora SMTP settings,
but just changed your computer to connect to the internet via your phone,
then you are probably correct that the server you had told Eudora to use
was not actually used, because of an intercept by your mobile provider:
> Sometimes I have the impression that when I am using a WLAN hotspot
> or GSM mobile data services to send emails, the emails do not arrive.
> I also have the impression that WLAN hotspots exchange the SMTP servers:
> I specify the SMTP server of my host, but perhaps the WLAN service changes
> that to the SMTP server of the WLAN provider.
Some networks "proxy" the SMTP service on the most common ports,
so that no matter what SMTP server name (or IP address) you supply,
they may indeed route it through their own servers;
all email clients are affected the same by any such proxying.
This neatly "solves" one common and annoying problem,
which is that of travelers who otherwise might find that their "home"
SMTP settings can not even initially connect from elsewhere,
who now just don't have to care, as the mail "goes right out" anyway.
However, if your network provider is suspected of harboring spammers,
then that very same "convenience" may turn into a different problem,
in which your messages are initially accepted from your computer
with no problem, until they get to their destination,
where an anti-spam system rejects them instead :)
If this is the case, try discussing it with your network provider.
Message recipients (which can be yourself) can track how messages
were actually routed by examining all the incoming "Received:" headers,
each of which is like a "postmark" saying that "this message arrived
at [this server], having just come from [that server or originator]"
> I asked my webspace provider and they said that my SMTP server is
> already a smarthost and that I just need to set up the email software
> accordingly. Apparently I have to authenticate myself before sending
> emails. What I don't know is if I have set up Eudora properly.
If the ISP's instructions and your settings were both completely known,
then that could be determined.
Successful sending (and final receipt by addressees) while using a normal,
non-proxying network would usually demonstrate correct settings, however.
> I also remember that in one case, while I was travelling in France last
> month, I was unable to send emails through the WLAN hotspot of a hotel.
> No idea if this was caused by the firewall of the internet service of
> the hotel or by something else.
Firewalls often block particular ports; most private networks and ISPs
block sending on SMTP port 25 from inside the network to any "outside" server,
because unauthenticated port 25 is a very wide open door for spamming;
the policies of network administrators regarding other ports
(and whether or not they supply a local alternate SMTP server for you)
may vary all over the map, so you just have to ask each one.
> In any case, the purpose of the exercise is to reduce
> the number of sent emails which are blocked by spam filters.
Sometimes the problem is with extremely over-zealous "spam filters,"
which make up for their poor performance at discriminating real spam
by adopting "shotgun" policies that also block vast amounts of non-spam.
Yahoo, for example, within the past year, went so far in that direction
that the problem of legitimate mail never arriving
became greater, for many users, than the former problem
of a percentage of all mail being spam.
Our university, in particular, was unable for quite some time
to communicate with either applicants or existing students who used Yahoo,
so we encouraged all of them to switch promptly to Gmail.
Gmail does the most accurate spam filtering we know of
for any "free account" provider, as well as letting the end user
make the final decision about suspected spam, rather than
even refusing to accept SMTP connections from us in the first place
(that's what Yahoo did, causing our own SMTP server
to "overflow" with an unsent mail backlog, hence drastically slowed
down our mail to all the rest of the world as well -- gee,
Yahoo, did we forget to thank you for acting like that?)
> In any case, the general problem is sending emails while travelling.
Try an SMTP server that uses SSL (on port 465),
which is the least affected by common firewalls and proxies,
and also talk to each other provider (mobile phone, hotel, etc.),
because the world does not have a single solution for all locations,
much as there is nothing else that works the same world-wide.
There are also vendors of remotely accessible SMTP services,
if your "home ISP" does not provide an "everywhere accessible" SMTP server,
but those might still be blocked in some places.
As to setting up Eudora in particular, there is nothing special;
you just specify the "best" SMTP server you can find,
as with any other email client on your own computer.
One easy solution to overcome any email "port problems"
is to use a web site to send your mail, whenever your local client can't.
Web sites which will send your mail include your own ISP's "webmail"
(now offered by most ISPs), or any external service like Gmail,
at which you can now "send mail as" other addresses of your own
(after a simple one-time "confirmation" process).
To enable Eudora to save a copy of mail sent from a web site,
you can "Bcc" a copy to yourself.
I personally actually have all my local mail forwarded
to a dedicated Gmail account, which I then use as my POP server
in place of my original ISP's POP server. I can also use Gmail's
free SMTP server (which uses SSL on port 465, and inserts no
gratuitous advertising into sent mail). With this simple
arrangement, I also get free spam filtering, free "webmail"
(my own Gmail account online), and free backup.
A related article (with good ideas, but some outdated "broken links"):
http://www.nber.org/REASON-FOR-REJECTION/smarthost.html
--
Alfred Molon
> Try an SMTP server that uses SSL (on port 465),
> which is the least affected by common firewalls and proxies,
> and also talk to each other provider (mobile phone, hotel, etc.),
> because the world does not have a single solution for all locations,
> much as there is nothing else that works the same world-wide.
Thanks for the informative post. I contacted my host and they said that
they have TLS on port 995. Is this also ok, since you mentioned SSL on
port 465?
I also gave a look at my Eudora settings. "Secure sockets when sending"
was set to "If available, STARTTLS". Under "Last SSL info" there was a
message that SSL had never been used before.
So I set it to "Required, STARTTLS" and sent a mail. Then I had a look
at "Last SSL info" and found the following:
--------------------------------
Server IP address: <IP address of my mailserver> Port: 25
...
...
Security parameters
Negotiation status: Succeeded
SSL version: TLS1
Cipher suite information
....
Encryption algorithm: EHD-RSA-DES- ......
....
Notes
Certificate bad: Destination host name does not match host name in
certificate
But ignoring this error because Certificate is trusted.
-----------------------------------
Clicking on "Certificate Information Manager" gives a load of details,
which I can post if necessary.
So what is happening? I'm using SSL, but on port 25? How is this
possible?
And what could possibly be wrong with the certificate?
On the "Certificate Information Manager" page there is a button "Import
certificate". Do I need to import a certificate here? Where do I get it
from?
--
Alfred Molon
Alfred Molon
mailserver I use has a certain name, but it appears that this name is
just an alias and the real SMTP server I'm using (and to which the
certificate is issued) is using a different name. I've replaced the
alias with the real name and now, after sending a mail, under "Last SSL
info" there is no more the error note that the certificate is bad.
However, the Last SSL info shows that port 25 was used. How is this
possible? If SSL was used, shouldn't port 465 or 995 have been used?
--
Alfred Molon
John H Meyers
> The Last SSL info shows that port 25 was used. How is this possible?
> If SSL was used, shouldn't port 465 or 995 have been used?
465 is only for SMTP, and 995 only for POP (993 only for IMAP);
this already shows how confused things are,
and perhaps explains why Eudora steered away
from even talking about or displaying port numbers,
although this turned out to be a frustration for ISP customers,
once their ISPs abandoned "support" for Eudora settings,
leaving users with no idea what to do now,
as well as no way to visually see and confirm
the port number which their settings will choose,
to try to match up with ISP port-oriented instructions --
such is the price of "hearing a different drummer :)
Here's my attempt at a "Rosetta stone" for this issue:
Each email protocol (POP, IMAP, SMTP) is,
by internet conventions,
associated with only two port numbers,
the higher-numbered of which is _only_ for SSL/TLS,
but the original port number can be used
for _either_ non-SSL or SSL/TLS traffic.
Eudora automatically chooses the port number
which matches your "Secure sockets" choice
(just not exactly as you are expecting,
because the "Alternate Port" is the higher number,
and the "STARTTLS" port is the original number :)
When a new convention became popular
for email clients to use port 587 for SMTP servers
that were specifically intended for direct client submission,
rather than also for forwarding between "post offices,"
this additional "check box" was added to Eudora as well (since 6.2.3),
now supporting SMTP on three standard port numbers.
The precise relationship between Eudora settings,
port numbers, and SSL/TLS is detailed here:
Setting "Port numbers" in Eudora (Windows and Macintosh)
http://eudorabb.qualcomm.com/showpost.php?p=37616
It is also possible to use any non-standard port numbers in Eudora,
but only via directly editing the options file (Eudora.ini)
If your settings cause port 25 to be used for SMTP,
whether with or without SSL/TLS,
it is likely that you will not be able to contact
any SMTP server outside of the network on which you connect
to the internet, because firewalls usually block outgoing port 25
to other networks (some ISPs will unblock individual subscribers
on request, if they convince the ISP that they need this unblocked
to reach some SMTP server at their external "domain host," etc.)
If your settings use SSL for SMTP on port 465, or use port 587 either way,
there is a greater likelihood that you won't be similarly blocked
(except right where I am, where the firewall administrator
wears a green beret, camouflage jacket, and patrols the perimiter
24 hours per day while carrying an assault rifle :)
As to "SSL vs. TLS," TLS is basically just a minor update of SSL,
and Eudora uses one library which should cover everything.
References for details about SSL/TLS:
http://en.wikipedia.org/wiki/Secure_Sockets_Layer
http://technet.microsoft.com/en-us/library/cc784450.aspx
Farther and wider:
http://en.wikipedia.org/wiki/Rosetta_Stone
http://www.mnsu.edu/emuseum/prehistory/egypt/hieroglyphics/rosettastone.html
http://www.britishmuseum.org/explore/highlights/highlight_objects/aes/t/the_rosetta_stone.aspx
--
Alfred Molon
> If your settings cause port 25 to be used for SMTP,
> whether with or without SSL/TLS,
> it is likely that you will not be able to contact
> any SMTP server outside of the network on which you connect
> to the internet, because firewalls usually block outgoing port 25
> to other networks
I have a website and am using the mailserver of the host. The ISP I am
using to connect to my mailserver is always outside the network of the
host, so according to your mail I would never be able to send emails
through the mailserver of my host, or did I misunderstand you?
In the meantime I realised that Eudora 7 uses StartTLS which apparently
builds encrypted connections on Port 25 (unless I misunderstood
something). Is this indeed the case?
My host told me that they block port 465 and that I should use port 995.
But Eudora refuses to send on port 995. I sent another email to my host
to clarify this port issue.
--
Alfred Molon
John H Meyers
> I have a website and am using the mailserver of the host. The ISP I am
> using to connect to my mailserver is always outside the network of the
> host, so according to your mail I would never be able to send emails
> through the mailserver of my host, or did I misunderstand you?
Blocking of port 25 between a local network and the "outside world"
is up to each network and ISP; it's pretty rare not to be blocked
by default, but perhaps it's already been arranged with your "usual" ISP.
If your hosting company is actually on the same network as your ISP,
that might also change things.
You mentioned that you can't connect from various spots while traveling;
if the attempt to connect is always on port 25,
it is generally not surprising when that port turns out to be blocked.
It's sometimes more surprising when it turns out _not_ to be blocked,
but as I think you already noted, there are some providers
(some fancier hotels, perhaps your GSM provider) who may proxy that traffic,
diverting it all to their own SMTP servers, if they want
to offer that as a wonderful selling point for their service.
We block _incoming_ port 25 to our unauthenticated internal SMTP server,
and our manager was quite perturbed when he was able to use that server
with his "home" laptop settings while traveling, until we were able
to show him that his hotel was performing that apparent miracle,
rather than our network letting him through :)
> In the meantime I realised that Eudora 7 uses StartTLS
That's of course under your control, not "automatically"
> which apparently builds encrypted connections on Port 25
> (unless I misunderstood something). Is this indeed the case?
STARTTLS (under "while Sending") would normally use port 25
unless "Use 587" is check-marked, in which case it would use 587.
"Use 587," in turn, would normally use 587,
unless "Alternate Port" is selected,
which trumps "Use 587" and would instead use 465 :)
Do you see any "Ports" category in your options?
If so, that "Esoteric" plugin can further mess with all defaults,
as can manual edits of Eudora.ini which would not show up anywhere
in the settings interface, so the most through inspection would be
to examine all lines in "Eudora.ini" which contain the string "port"
(perform a case-insensitive search).
File "Eudora.log" would, if set to log these events, also demonstrate for sure
which ports were being used for any actual connections.
> My host told me that they block port 465 and that I should use port 995.
By "my host" do you mean an external web hosting company
(kasserver.com ?), describing their POP and SMTP services,
rather than any ISP speaking about what their firewall blocks outgoing?
Is that an exact quote of what they said?
The language of that sentence is just a bit suspicious to me,
because a server isn't usually described as "blocking" any ports;
rather, it is described as having services listening on specific ports,
and any ports on which it isn't listening will simply not respond
(or may default to "refusing" connections).
Also, in the generally recognized list of internet port numbers,
which fall into various classes:
http://www.iana.org/assignments/port-numbers
you will find only these sanctioned uses of port 995:
pop3s 995/tcp pop3 protocol over TLS/SSL (was spop3)
pop3s 995/udp pop3 protocol over TLS/SSL (was spop3)
> But Eudora refuses to send on port 995
How did you try to tell Eudora to send mail on port 995?
(it's not impossible to actually force it to try SMTP on port 995,
but that's not usually what this could possibly mean).
There is actually a provision for POP servers (which use port 995 for SSL/TLS)
to optionally accept commands for sending mail -- if that's what your hosting
company meant; however, I would think they would have clarified that.
It's also a very rare thing, because it's a rare email client
which is even written to accommodate this rare facility.
This is the setting, FWIW (it becomes a "link" when in a Eudora message,
and can be clicked on while holding [Alt] on the keyboard):
X-Eudora-Option:UsePOPSend
Further description is in your user manual, and in built-in Eudora "Help,"
and at: http://www.eudora.com/techsupport/ini.html
I have no idea whether this is still effective, or how it either
interacts with or might ignore a personality's SMTP settings.
When you use a hosting company's server, you have to find out
what it's specific specs are, which are often unpublished;
another alternative is to use SMTP servers provided by
one's own astute "home" ISP, which are ever more commonly
offering "use from anywhere" SMTP servers,
or you can use Gmail's (free, but not for huge volume),
or any other -- nothing stops one from using
any independent server that will let one log on and send,
and that one's immediate location or connection
isn't blocking (outbound) with a firewall;
it need not have any relation to one's POP account or web host.
Statistics on one web hosting company:
http://www.webhosting.info/webhosts/reports/total_domains/KASSERVER.COM
http://whois.domaintools.com/kasserver.com
--
Alfred Molon
> STARTTLS (under "while Sending") would normally use port 25
> unless "Use 587" is check-marked, in which case it would use 587.
>
> "Use 587," in turn, would normally use 587,
> unless "Alternate Port" is selected,
> which trumps "Use 587" and would instead use 465 :)
<snip>
> > My host told me that they block port 465 and that I should use port 995.
>
> By "my host" do you mean an external web hosting company
> (kasserver.com ?), describing their POP and SMTP services,
> rather than any ISP speaking about what their firewall blocks outgoing?
>
> Is that an exact quote of what they said?
My site is at molon.de and I use molon.de email addresses. The hosting
company (i.e. the "host") is all-inkl.com and the mailserver is
*.kasserver.com.
When travelling I connect through WLAN hotspots or other ISPs and try
sending emails.
In any case I emailed again the host and they replied that they use
StartTLS on Port 25 which is the more modern method. They do not support
the old secure SMTP on port 465.
In any case I tried to configure Eudora to send on port 587 and it
worked. The eudora.log file contains a line like this one:
5024 16: 0.26 Open aa.bb.cc.dd:587
where "aa.bb.cc.dd" is the IP address of my mailserver which I have
substituted with letters.
So it seams that StartTLS over port 587 works. Should I configure all my
mail account personalities in Eudora to use port 587 for sending?
--
Alfred Molon
John H Meyers
> I emailed again the host and they replied
> that they use StartTLS on Port 25
> which is the more modern method.
So apparently Gmail, Comcast, Yahoo, AT&T, and all the rest
are just not modern, because they all specify SSL/TLS on port 465 :)
For example:
http://mail.google.com/support/bin/answer.py?answer=13287
http://help.yahoo.com/l/us/yahoo/mail/original/mailplus/pop/pop-14.html
http://help.comcast.net/content/faq/How-to-configure-Outlook-Express-to-send-and-receive-E-mail-while-traveling
> They do not support the old secure SMTP on port 465.
It's just the same SSL/TLS, but on port 465,
which is becoming practically universal (see list above),
although many major players also "listen" for SSL/TLS on port 587
(and sometimes even port 25), for various reasons,
some of which may be imagined from this chart:
Port, Authentication, SSL/TLS, Eudora SSL (sending)
---- -------- -------- -----------------
25, Optional, Optional, Never or STARTTLS
587, Required, Optional, Never or STARTTLS with "Use 587"
465, Required, Required, "Alternate Port"
Where "Optional" means that servers in general don't have to require it,
although any particular server MAY require it, if the ISP so chooses :)
> In any case I tried to configure Eudora to send on port 587 and it worked.
> The eudora.log file contains a line like this one:
> 5024 16: 0.26 Open xxx.xxx.xxx.xxx:587
Some ISPs just don't document (or happen to tell you)
everything which will work, but if it does work,
then the server's actual behavior is "the last word" on the subject :)
> Should I configure all my mail account personalities in Eudora
> to use port 587 for sending?
The "relay" feature in Eudora is a convenient way
to "funnel" all mail sending through one server, if appropriate;
you choose one "SMTP relay" personality in "Sending Mail,"
and then you mark "Use relay personality" in the "Properties"
of other personalities (via the "Personalities" tool window),
so that no matter which personality is used to compose mail,
all sending is via one common SMTP server.
Not only is this convenient (especially when traveling,
even between home and office, for those who simply
switch local outgoing servers), but when some personalities
have different POP usernames/passwords than the SMTP server,
this is the only way to transfer the "sending"
to another personality which knows the different SMTP password.
One special case where a problem occurs is if your "common"
SMTP server is so restrictive that it won't accept any
"From: someone_else" headers in your outgoing mail,
when some of your personalities are unrelated
to the ISP who provides the SMTP server.
That, of course, is something to work out with the server provider,
or use another SMTP provider for that account (or all accounts),
and isn't really a Eudora issue.
--
David Lesher
>> The Last SSL info shows that port 25 was used. How is this possible?
>> If SSL was used, shouldn't port 465 or 995 have been used?
>465 is only for SMTP, and 995 only for POP (993 only for IMAP);
>this already shows how confused things are,
>and perhaps explains why Eudora steered away
> from even talking about or displaying port numbers,
>although this turned out to be a frustration for ISP customers,
>once their ISPs abandoned "support" for Eudora settings,
>leaving users with no idea what to do now,
>as well as no way to visually see and confirm
>the port number which their settings will choose,
>to try to match up with ISP port-oriented instructions --
>such is the price of "hearing a different drummer :)
As explained to me:
There are two ways to use SSL with IMAP {and POP, but I was asking about
IMAP}. Some clients support both, some one.
1. Start an SSL connection. Then do IMAP over the SSL connection.
2. Initiate IMAP. If the server says it supports STARTTLS, the client
issues the STARTTLS command. Negotiate an SSL connection, then proceed.
Type 1 is called IMAPS and uses port 993. (SMTPS (aka SMTP-over-SSL) runs
on port 465.)
Type 2 can/does use the same port as non-SSL.
My interest is I want to set clients to use type 1. Why? Because too
many ""helpful"" clients will offer to revert to unencrypted if SSL
fails. I do not want that; I want the connection to stop before any
traffic is sent in the clear..
--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
John H Meyers
[changing the original topic from SMTP to IMAP]
> As explained to me:
> There are two ways to use SSL with IMAP
> (and POP, but I was asking about IMAP).
IMAP on (SSL-only) port 993 will not be confused with
POP on (SSL-only) port 995, nor will optional-SSL IMAP
(on port 143) be confused with optional-SSL POP (on port 110).
None of the above will be confused with SMTP
on port 25, 587, or 465, either.
In other words, there is normally only one protocol per port
(but there are two or three possible common ports per protocol,
which is what's always confounding everyone about their settings :)
> Some clients support both, some one.
>
> 1. Start an SSL connection. Then do IMAP over the SSL connection.
>
> 2. Initiate IMAP. If the server says it supports STARTTLS, the client
> issues the STARTTLS command. Negotiate an SSL connection, then proceed.
>
> Type 1 is called IMAPS and uses port 993.
> SMTPS (aka SMTP-over-SSL) runs on port 465.
>
> Type 2 can/does use the same port as non-SSL.
It's evidently on a per-port basis,
and must be automatically handled as each port requires.
Also, SMTP is only for sending mail,
POP and IMAP are for handling received mail,
although POP may have an optional "backdoor" for sending,
if an ISP hooks it together with its own SMTP server.
> My interest is I want to set clients to use type 1. Why? Because too
> many ""helpful"" clients will offer to revert to unencrypted if SSL
> fails. I do not want that; I want the connection to stop before any
> traffic is sent in the clear..
What you want does not require the "SSL-only" ports (993, 995, 465),
but if the servers which you use offer those ports,
then you can certainly specify them in your client,
which for Eudora means choosing "Required, Alternate Port" --
the exact same wording for any protocol (IMAP ,POP, SMTP).
As to ports which can be used either with or without SSL/TLS,
Eudora's options clearly distinguish
"If available, STARTTLS" from "Required, STARTTLS"
(and from the above "Required, Alternate Port"),
so hopefully Eudora will abide by which one is selected,
which would mean aborting if you say "Required, STARTTLS"
but the server does not "advertise" its SSL/TLS capability,
and/or won't respond properly to its use.
No other email client that I've used even distinguishes
"Required" from "If available" in its settings,
which I suppose could leave one to wonder
what its actual policy might be.
Any client which has logging ability (as Eudora does)
provides a clear record of what actually does happen,
as a check on whether the requested policy is followed,
and one can always resort to a network monitor
(e.g. WireShark) to check up on any non-logging client.
--
David Lesher
>IMAP on (SSL-only) port 993 will not be confused with
>POP on (SSL-only) port 995, nor will optional-SSL IMAP
>(on port 143) be confused with optional-SSL POP (on port 110).
>None of the above will be confused with SMTP
>on port 25, 587, or 465, either.
Don't think I said they would...
>In other words, there is normally only one protocol per port
>(but there are two or three possible common ports per protocol,
>which is what's always confounding everyone about their settings :)
No, you may have POP [or IMAP, or SMTP] on port X, OR POPoverSSL on the
same Port X. [My Type 2]
>> 1. Start an SSL connection. Then do IMAP over the SSL connection.
>>
>> 2. Initiate IMAP. If the server says it supports STARTTLS, the client
>> issues the STARTTLS command. Negotiate an SSL connection, then proceed.
>>
>> Type 1 is called IMAPS and uses port 993.
>> SMTPS (aka SMTP-over-SSL) runs on port 465.
>>
>> Type 2 can/does use the same port as non-SSL.
>It's evidently on a per-port basis,
>and must be automatically handled as each port requires.
?
>Also, SMTP is only for sending mail,
>POP and IMAP are for handling received mail,
>although POP may have an optional "backdoor" for sending,
>if an ISP hooks it together with its own SMTP server.
No disagreement there, either...
>> My interest is I want to set clients to use type 1. Why? Because too
>> many ""helpful"" clients will offer to revert to unencrypted if SSL
>> fails. I do not want that; I want the connection to stop before any
>> traffic is sent in the clear..
>What you want does not require the "SSL-only" ports (993, 995, 465),
>but if the servers which you use offer those ports,
>then you can certainly specify them in your client,
>which for Eudora means choosing "Required, Alternate Port" --
>the exact same wording for any protocol (IMAP ,POP, SMTP).
I have seen clients that, when set for 25/110/143, and encrypted; DO
offer unencrypted as an alternative. Eudora was one. I regard that as
evil.
Ideally, I control the server, and don't ever allow cleartext
period. Then it does not matter if it is Type 1 or Type 2,
{say} 993 vs 143.
But if I don't, I prefer the Type 1 setup. Then the user has
muck with both the SSL setting AND the port #'s to get it
working unencrypted.
>Any client which has logging ability (as Eudora does)
>provides a clear record of what actually does happen,
>as a check on whether the requested policy is followed,
>and one can always resort to a network monitor
>(e.g. WireShark) to check up on any non-logging client.
The user has her machine. I have no good way of monitoring
her logs when she's 600 miles away. If I can get the ISP
to send me log extracts, great, but the chances of same
are poor.
John H Meyers
> you may have POP [or IMAP, or SMTP] on port X,
> OR POPoverSSL on the same Port X. [My Type 2]
SSL is in a different "layer" than the email protocol,
so I was counting only the email protocols (POP, IMAP, SMTP),
where there is no more of one of those associated with any port,
even though each email protocol has two or three
"commonly used" standard ports.
BTW, one reason I gave all my points
was to provide general information for everyone,
even if you didn't ask for or need all of it yourself,
so please excuse my replying with more than was necessary :)
> I have seen clients that, when set for 25/110/143, and encrypted;
> DO offer unencrypted as an alternative. Eudora was one.
> I regard that as evil.
What email client does NOT offer a choice to specify "no SSL"?
(and what email client does not even _default_ to this?)
Eudora gives the user a choice. If the user says "required,"
then it's required; if the user says "if available,"
then it's "if available" -- there is no case
where Eudora will do anything that the user didn't approve.
Eudora's "if available" choice gives the user a way to say
"use the highest capability that this server offers,"
IF they are willing to accept it either way,
and if they are not, then they can say "Required,"
and accept "no service" if the server itself doesn't handle it.
Why not instead take this campaign to server operators,
where it belongs, and declare them "evil"
if they even allow (or offer _only_) unencrypted connections?
> Ideally, I control the server, and don't ever allow cleartext
> period. Then it does not matter if it is Type 1 or Type 2,
> {say} 993 vs 143.
> But if I don't, I prefer the Type 1 setup. Then the user has
> muck with both the SSL setting AND the port #'s to get it
> working unencrypted.
That's exactly what you get with Eudora!
There can be an unencrypted session only if
the user says "None" AND the server handles unencrypted traffic,
or if the user says "If available"
AND the server doesn't even offer encryption at all.
Saying "Required" _forces_ SSL on ANY port at ANY server whatsoever,
(giving a "failure" if the server doesn't support the request),
no matter whether it's "Required, STARTTLS" (your "type 2")
or "Required, Alternate Port" (your "type 1"),
so "where's the beef" about this?
If you are the server operator, and don't even offer
unencrypted sessions, then Eudora can't force your server
to do anything you did not offer, so no matter how I look at Eudora,
I can not see where it isn't just slightly better
than the rest of the field of popular clients,
because it's the only one I know which recognizes
the very set of details which you have brought up,
and can be set to do exactly what you want
(or to do what someone else wants,
in case there is anyone whose wants differ from yours).
> The user has her machine. I have no good way of monitoring
> her logs when she's 600 miles away. If I can get the ISP
> to send me log extracts, great, but the chances of same
> are poor.
What do you do for a user who has Outlook Express?
How do you see whether she has correctly required SSL,
or has let it default to unencrypted?
Certainly it's just the same for Eudora, where what you want
is satisfied by making sure that she chooses "Required"
(whereas with Outlook Express it's to make sure that
she check-marks "SSL") and then I'm still not sure
whether or not Outlook Express enforces that on ports 110/143/587.
My point about logging was just that it could be a tool
for detecting whether Outlook Express or other clients
enforce "SSL" requests or not, and to prove whether or not
Eudora might have a bug, not obeying exactly what it's told,
but I've never heard any suspicion yet that Eudora could fail
when told "Required" for SSL (whether that's "Required, STARTTLS"
or "Required, Alternate Port").
It seems to me that Eudora is the only client which obviously
has taken everything you have brought up into account,
and is certain to do exactly what the user tells it to,
so I can't see why you are not quite satisfied with that,
To go one final step further, all of the above concerns only
traffic on networks between email clients and ISP (or company) servers,
and can assure "end to end" encryption between sender and recipient
only when their messages never travel between domains
(and when "the boss" or "the administrators" are not
reading the messages anyway, unencrypted, on the servers themselves).
If sender and recipient are in different domains,
the SMTP traffic between one domain's server and another
is still always unencrypted anyway, so if you want greater privacy,
be sure to also use S/MIME or PGP/GPG upon message content;
then only those people with the Alternate Decryption Keys (ADK)
can snoop into them, unless of course the NSA (in USA)
has cracked all those systems anyway, which no one would know
for the next 50 years, when any such fact would finally be de-classified :)
http://www.cnn.com/SPECIALS/2001/nsa/stories/crypto.history/
http://www.espionageinfo.com/Ec-Ep/Enigma.html
http://www.amazon.com/Enigma/dp/0471407380
http://www.woolamaloo.org.uk/2004/10/enigma-more-declassified-information.htm
http://it.slashdot.org/article.pl?sid=06/02/26/0646215
--