[MlMt] return code 554 (expected 250)

[Bill Cole]

On 22 Sep 2014, at 20:58, Paula R. T. Coelho wrote:

> ah! the only thing i can think of is that this started happening since 
> i arrived in Spain for a work meeting...

Which is indeed the likely explanation...

> On 23 Sep 2014, at 2:54, Paula R. T. Coelho wrote:
>
>> very weird problem...
>>
>> in the last 35 hours or so every time i try to send emails *from* two 
>> specific accounts (out of 4 in total), i get the following message:
>>
>> Unexpected return code 554 (expected 250):
>> “5.7.1 <164.Red-83-61-103.dynamicIP.rima-tde.net[83.61.103.164]>: 
>> Client host rejected: Access denied”.

Unpacking that:

554 is a standard reply code in SMTP used by a server to tell the client 
that its last command failed without specifying a particular cause, 
simply that the failure should be deemed persistent and that the same 
transaction should not be re-tried automatically.

5.7.1 is an "enhanced" code that can be used with any 55x reply code 
which indicates that the failure is due to an authorization failure 
(i.e. a policy restriction rather than a syntax error, non-existent 
recipient address, etc.)

The remaining text appears to be the IP address of your client machine 
preceded by the hostname it resolves to and the human language (of a 
sort) explanation of the reason for the failure. This form using the 
"Client host rejected" phrase is indicative of the Postfix MTA software 
applying a local access rule based solely on the IP address and/or 
hostname of the sending client machine.

In short: It looks like the SMTP server you were talking to does not 
accept mail from the Telefonica de España IP address you are 
(temporarily) using. That is likely to be a ban that includes most of 
the surrounding TdE network: either an IP range or due to the telltale 
generic pattern in the hostnames which indicates that they are assigned 
to TdE customers temporarily and dynamically.

It is worth noting that many (perhaps MOST) SMTP servers would reject 
mail from that network unless the client successfully authenticates to 
an authorized account. It has been used by TdE for dynamic assignments 
for many years and is (properly) listed on the most widely used DNS 
blacklists specializing in identifying such networks. Dynamically 
assigned addresses are widely distrusted as mail clients (absent 
authentication) because that's where most end-user PCs are, and hence 
where most spamware-compromised machines are.

>> at first i thought the problem was at the smtp server (the two 
>> accounts use the same smtp server but different login). but after so 
>> many hours, i suspected of it and tried to send email from the same 
>> problematic account via ipad and i did manage! mail.app has the same 
>> problem as mailmate though, so it is a problem related to my laptop.
>>
>> i swear the problem started out of the blue, i haven't changed 
>> anything... (that i can remember of).
>>
>> any thoughts? i'm lost...

There are 3 possibilities that come to mind:

1. This is just an unusual (and maybe unwise) configuration by your mail 
provider to absolutely reject mail from a network with a long history of 
sending spam, without making exceptions for authenticated customers. The 
only solutions in this case are to not use that network to send through 
that SMTP server or to persuade the provider to lift the ban.

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.

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.