[MlMt] return code 554 (expected 250)

[Bill Cole]

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.