I have started to see an intermittant error when sending email via my application.
System.Net.Mail.SmtpException: Service not available, closing transmission channel. The server response was: 4.4.2 service timed out.
Now obviously it's timing out for some reason, but any ideas as to why this is happening now? This is the first time I've seen it happen.
Some things to check:
has anything on the server side changed? Did the admins add some kind of greylisting, perhaps?
what happens if you connect to the server directly via telnet on port 25?
does this occur from other applications, as well (e.g. your desktop E-mail client) ?
Related
Sending SMTP mail via an Office 365 mail server, using .NET System.Net.Mail.SmtpClient I'm getting the following error:
The server response was: 4.3.21 Mailbox server busy; mail intentionally delayed
I can't find any reference to this specific code anywhere - the closest thing I can find is 4.3.2 mailbox busy
It seems to be a transient error, but I'm getting a lot of them.
Any idea what the code means?
I have a very curious issue with an application. When debugging locally, I can send emails just fine using a client's G Suite email credentials:
<smtp deliveryMethod="Network" from="client#customdomain.com">
<network defaultCredentials="false"
host="smtp.gmail.com"
port="587"
userName="client#customdomail.com"
password="supersecret"
enableSsl="true" />
</smtp>
Now, it's very important to note that the application will send just fine with the credentials when running on localhost using Visual Studio. However, when deploying to LIVE and using the exact same credentials, the application refuses to send and I only get the canned response back saying "Failure Sending mail".
I have enabled "less secure applications" in the settings and have verified the "suspicious activity" from the server's IP address. I can also log in to the Gmail account from the server using RDP and opening Firefox to go to Gmail.com.
No firewall rule has been set to block SMTP or anything on port 587.
UPDATE: the materialized error message is
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 74.125.192.108:587
74.125.192.108 being smtp.gmail.com's IP Address (or one of them, at least)
UPDATE 2: I can also not get Thunderbird on the remote server to send an email using the supplied credentials, however it can connect via IMAP and download the contents of the inbox just fine.
Well in this very specific case, it was the fault of the Amazon infrastructure this application ran on. Either amazon themselves, or the reseller changed a policy that ended up blocking communications on ports 465, 587 and 993 (and probably others too).
The "solution" was to nag them to sort it out.
I am using PHP's mail function to send messages to the users of an application.
But I have been getting reports that some people don't receive them, and that others have arrived up to a couple of hours later.
So I was looking through /var/log/maillog, where I came across this message a lot:
postfix/smtp[22966]: connect to mx1.hotmail.com[65.55.37.104]:25: Connection timed out.
There were a lot of delays over 1000 sec in the log.
I have checked the firewall settings, and there are no rules stopping port 25, and this problem is not consistent, some emails go out fine, while others are sent with a long delay, and others are not sent at all.
Any suggestions for what to try next?
Running on CentOS 6.5.
From what you describe, it sounds like some of the remote mail servers that you are sending to could be greylisting your mail server, perhaps because it thinks that your mail server could be a spammer.
To see if your mail server has a glaring problem that would cause other mail servers to think it's a spammer, try sending a message from your mail server to check-auth#verifier.port25.com. This service will do a bunch of checks, and you'll get a report back with ton of information, such whether or not your mail server's DNS is setup correctly, whether your mail server's IP is on any black lists, if you have a problem with your SPF records, etc.
We set up a VM in Windows Azure cloud service. However, the SMTP is not working. All the messages are queuing in the mailroot\queue folder. Here are some delivery failure message received.
Delivery Status Notification (Failure)
Action: failed
Status: 5.5.0
Diagnostic-Code: smtp;550-5.7.1 [x.x.x.x] The IP you're using to send mail is not authorized to 550-5.7.1 send email directly to our servers. Please use the SMTP relay at your
550-5.7.1 service provider instead.
Delivery Status Notification (Failure)
Action: failed
Status: 5.5.0
Diagnostic-Code: smtp;550 OU-002 (COL0-MC1-F41) Unfortunately, messages from x.x.x.x weren't sent. Please contact your Internet service provider since part of their network is on our block list.
How can it be solved? Please help. Thanks
That looks to me as though the receiving hosts are blocking you from sending to them, probably because your IP is on a blocklist. You can check that on http://mxtoolbox.com/blacklists.aspx
You might want to raise a support ticket with Azure and complain, and/or alternatively ask them for their SMTP server settings, which will relay the mail through their servers (which should never be blocked).
I was wondering if anyone might be able to explain to me why it's taking nearly 30 seconds each time my Java web app sends an email using Gmail's SMTP server? See the following timestamps:
13/04/2010-22:24:27:281 DEBUG test.service.impl.SynchronousEmailService - Before sending mail.
13/04/2010-22:24:52:625 DEBUG test.service.impl.SynchronousEmailService - After sending mail.
I'm using spring's JavaMailSender class with the following settings:
email.host=smtp.gmail.com
email.username=myaccount#gmail.com
email.password=mypassword
email.port=465
mail.smtp.auth.required=true
Note that the mail is getting sent and I'm receiving it fine, there's just this delay which is resulting in a slow experience for the application user.
If you know how I can diagnose the problem myself that would be good too :)
It might be that gmail uses this delay to prevent spammers from using their SMTP server from the "outside": if the SMTP is called from the actual webmail client it would not use this delay.
In order to test this, you could open a telnet session to port 25 and do a manual SMTP session
(Search the web for SMTP HELO for examples)
GMail uses SSL for connection. To validate SSL certificate properly certain time is needed. Exact time depends on complexity of the certificate chain and use and accessibility of CRLs and OCSP checking. It's very likely that Java checks OCSPs for the certificate(s) presented, and this can be slow.
Try running your application on different system (preferably in other subnet) to exclude influence of firewalls. Maybe some part of communication (either SMTP itself, or CRL retrieval or OCSP checking) is slowed down by the firewall.
Depending on your OS, you should have a proper mail system that takes care of actually sending mails outside your network.
For instance, Postfix can do the job nicely. The configuration of Postfix would be on another thread, but typically Postfix would accept mails from your LAN (accepting to be a relay for your LAN) and would transfer the mails to gmail.
This is a exemple as to how setup postfix to have gmail as relay.
Having a mail service taking care of the relay of Gmail mails allows your Java application to be freed almost instantly (Postfix absorbs the mail, store it in its queue and forward it to Gmail itself).