On 23 Sep 2014, at 17:45, Paula R T Coelho wrote:
wow bill... that opened a whole new world to me. thanks :)
You're quite welcome. I do aim for completeness...
2. There is something which you can fix with your connection and/or
authentication settings for that SMTP server. This can be a problem
in both
Mail and MailMate if you imported slightly bad account settings from
Mail
into MailMate. One issue that can go unnoticed is if your provider's
SMTP
server is accessible both over the standard SMTP port (25) and the
mail
submission port (587) with subtly different policy rules applied. The
MacOS
Internet Accounts subsystem by which Mail configures its accounts
uses a
procedure for quietly figuring out what port and SSL/TLS settings
work with
a particular server which has a history of incorrectly preferring
port 25
when in fact port 587 is a better choice. It is quite reasonable for
a port
25 SMTP service to ban dynamic ranges outright if the provider also
allows
authenticated customers to submit mail using port 587. To fix that
particular problem, you can explicitly change the account to
explicitly use
port 587. If your provider does not offer a 587 submission service,
you'll
simply get a failed connection and you can switch it back. I've also
seen
reports of Mail trying to send messages in a SMTP session even after
it has
failed to authenticate or to set up a SSL/TLS session to encrypt
traffic
but I don't think MailMate would ever do that, so I doubt the problem
includes an authentication failure. It MAY be that neither program is
attempting authentication because you don't have the account set to
use it.
That error could go unnoticed if this SMTP server is run by your
usual
connection provider, as it may not require authentication for IP
address on
their own network.
i checked that out and i have port 587 set, with authentication but
no SSL
(??? the IMAP login requires SSL though :-\), which is what the FAQ of
my
university tells me to do.
That's odd. It is generally wrong to not use transport encryption on a
port 587 submission service. Unfortunately, the precise technical
meaning of "SSL" checkboxes in mail clients varies greatly between
clients and even different versions of the same client, so even some
support documentation can get it wrong. The problem is that there are
really 3 distinct options for transport encryption: none, SSLv3
"wrapper" mode (specified in early SSLv3 draft specs and hastily adopted
by Microsoft,) and TLS (the name given to the open standard based on
SSLv3). Mail clients (even MailMate) typically offer only a yes/no
choice to use "SSL" when in fact the most common, secure, and
standard-compliant option is to use TLS, which is what they (mostly)
really do when told to use SSL.
Shorter: It may be useful to check the misnamed "Require SSL" box on
that account in MailMate and see if that helps. Whether or not a session
is encrypted can influence which authentication methods a mail client
tries, which could be a piece of the problem. The worst thing that could
happen from that is your SMTP session failing faster.
3. It is possible that the network you are connecting to directly is
hijacking your attempts to connect to an external SMTP server and
imposing
a proxy between your machine and the server which breaks your ability
to
send mail. This is often done with a goal of blocking abuse of
networks
that provide unrestricted access to random visitors, but some of the
most
common "transparent" proxy implementations (e.g. Cisco's PIX & ASA
firewalls) mangle SMTP so badly that it is impossible to do secure
mail
submission through them.
in this scenario, would make sense to have the gmail accounts
working but
not my university smtp?
Maybe. The subtleties of what gets broken by the various "transparent"
SMTP proxies are more than I care to keep in my head. However, I believe
that GMail requires TLS on port 587, which smarter proxies support by
becoming *truly* transparent (i.e. no longer mangling traffic) when they
see the STARTTLS command. That COULD mean that a TLS-encrypted session
will work where an unencrypted one breaks.
The other thing to try would be to compare the settings for the account
on your iPad with how it is set up on the laptop. If they are both
connected to the same network but the iPad can send while the laptop
can't, something must be different.
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate
