Settings for Eudora 7 for using a smarthost

In article <op.uge7iowynn735j@miu.edu>, John H Meyers says...
> 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

On Mon, 25 Aug 2008 08:14:48 -0500, Alfred Molon wrote:

> 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/a...y?answer=13287
http://help.yahoo.com/l/us/yahoo/mai...op/pop-14.html
http://help.comcast.net/content/faq/...hile-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.

--

"John H Meyers" <jhmeyers@nomail.invalid> writes:

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

On Tue, 26 Aug 2008 10:50:49 -0500, David Lesher wrote:

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

--

"John H Meyers" <jhmeyers@nomail.invalid> writes:


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

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

On Tue, 26 Aug 2008 13:27:45 -0500, David Lesher wrote:

> 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...rypto.history/
http://www.espionageinfo.com/Ec-Ep/Enigma.html
http://www.amazon.com/Enigma/dp/0471407380
http://www.woolamaloo.org.uk/2004/10...nformation.htm
http://it.slashdot.org/article.pl?sid=06/02/26/0646215

--