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.
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
http://lists.freron.com/listinfo/mailmate

Reply via email to