[MlMt] return code 554 (expected 250)

Paula R T Coelho paulartcoelho at gmail.com
Tue Sep 23 17:45:57 EDT 2014


wow bill... that opened a whole new world to me. thanks :)

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

​it is a university smtp server and i know that recently they have been
hacked. so it doesn't surprise me that they are enforcing strong unwise
rules..​. i'm only able to reply to the messages through their web
interface these days.


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


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

cheers,
paula
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freron.com/pipermail/mailmate/attachments/20140923/00552829/attachment.html>


More information about the mailmate mailing list