[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