We are running our own DevOPS Server in some virtuell Windows Server environment.
From time to time (it differs from weeks to months) not a single email gets sent by the server, when e.g. a new WorkItem is assigned to someone or a build pipeline fails.
All co-workers receive their other mails (from anyone) normally as their used to, when this happens.
Connecting via rdp session to the server is also no problem.
It works for a undefined periode of time, after the server gets restarted.
The email account which is used to send the email notifications by the server, is an outlook365 account.
After restarting the whole windows server inside the virtual machine, the emails are getting send and everyone in the company is email bombed than by the server :) whith every mail that didn't get send by azuredevops server from the day when the problem occured (this is not always clear, when it starts, because we are not always recognizing it so fast when it ouccures) until the time we restart the server.
Any one here having any idea, what could i check when the problem occurs again?
thanks for any hint in advance
Related
My Ubuntu based webserver needs to occasionally send emails. My python code is:
withsmtplib.SMTP('smtp-relay.gmail.com', 587, 'mydomain.com') as s:
s.sendmail(fromaddr, toaddr, msg.as_string())
s.quit()
I have
a Google workspace account
am using IP authentication (not SMTP auth)
my staging and production servers added as trusted IPs (staging is
local, production is cloud)
This setup had been working fine for 6+ months.
Two days ago I upgraded Ubuntu from 20LTS to 22LTS and python 3.8 to 3.10. Now the email is working fine on the staging server, but production keeps throwing:
Invalid credentials for relay [...]. The IP\n5.7.1 address you've registered in your G Suite SMTP Relay
service doesn't\n5.7.7 match domain of the account this email is being sent from. If you are\n5.7.1 trying to
relay mail from a domain that isn't registered under your G\n5.7.1 Suite account or has empty envelope-from,
you must configure your\n5.7.1 mail server either to use SMTP AUTH to identify the sending domain or\n5.7.1 to
present one of your domain names in the HELO or EHLO command. For\n5.7.1 more information, please visit
https://support.google.com/a/answer/6140680#invalidcred ...
Any suggestions?
Edit 1:
I fired up my old ubuntu server in the cloud. I added its new IP as trusted on Google. The email worked fine. I can think of only three possibilities
Google somehow recognizes and trusts requests coming from the old
device (even though it now has a different IP)
Linode is somehow not sending the correct IP address from my new
server
Something broke during the Ubuntu upgrade
I find each of the 3 possibilities quite bizarre and unbelievable at this point, but I'll keep researching.
PS: Three factoids that may/may not be relevant:
I upgraded the staging server in place. For production I spun a new
instance, made sure everything else was working fine (except
email) and then transferred IP from the existing instance to new
When I log in to my google admin account to edit trusted IP list, my
IP is the same as staging server. I don't think I have the same
option for production, since it's an Ubuntu server I manage through SSH
I found some comments online (none in official documentation), that
the reverse DNS needs to be setup before Google would relay anything.
I set up the entry about 20 hours ago for production, but still
getting the same error. And for my staging server, I don't have rDNS
and it still sends emails (it's accessible from the internet, but I
don't have a static IP)
PPS:
The sender email is someuser#mydomain.com (not #gmail.com)
The production server is hosted on linode.com
This post comes close
to discussing a similar situation, but that is focused more on
signing in. My setup uses IP authentication, not SMTP auth. Plus it was working fine until Friday (8/12)
It turned out to be a really frustrating issue. My best guess is that Linode's Ubuntu 22.04 repository has issues. We were thinking of migrating to AWS anyway, this gave us a strong impetus.
Anyway, here are some tips from my experience that a future reader might be able to benefit from
When you're using IP authentication for Google's SMTP relay, the updates are fairly quick. I ended up spinning at least 5 instances with 5 different IPs, and each time Google was able to trust my IP within 2-3 seconds (after I updated in workspace console)
Google didn't care about my reverse DNS entries. I had read some comments online that Google wouldn't relay without rDNS, but I didn't face any such problems (at least not any rDNS I was setting. The ISP or the cloud provider have a default entry, that was good enough - if Google was even looking for it). This one was particularly problematic because that information can take hours to propagate, and I kept thinking maybe my code will start to work tomorrow.
The error message I received from Google was pretty uninformative. I contacted Google support to see if they have access to anything more meaningful on the server side. They didn't - it was a waste of time
It was somewhat helpful to run a fake SMTP server to see what my client was sending. I got it from this post. I ran it for a setup that was working and one that wasn't. In my case, the communication received was identical. Though in hindsight maybe I would've seen some differences if I ran it on a remote server.
python -m smtpd -n -d -c DebuggingServer localhost:2500
When I go to https://mxtoolbox.com/diagnostic.aspx, enter my domain (pairofdocs.net), and click ‘Test email server’, I get the error message:
Connecting to 23.23.216.253
2/19/2021 9:23:30 AM Connection attempt #1 - Unable to connect after 15 seconds.
I have no idea why this is happening – any suggestions?
I have used the test previously and it worked. My domain is configured as follows:
DNS – on NameCheap.com
Web site (a simple one) – on Amazon Web Services
Email – handled by Zoho
I rebuilt my domain about six months ago, on a new AWS instance - whose IP address is 23.23.216.253, and do not recall the problem’s having happened prior to the rebuild.
Since your Email hosting is outsource to Zoho, there is a pretty good chance the email server has been setup correctly and has a pretty decent uptime.
It is likely the problem you are having is with how you are connecting to the email server although the error you've provided shows what seems to be an offline email server.
I recently switched from an axoim exchange mail server to microsoft 365 exchange server. Now my email address is still the exact same as it was, and most of the incoming mail comes to my new server and address, but it looks like some incoming mail is still going to the old server. Why is that and what can i do to address it?
I'm assuming that you changed the MX records for your domain, so that they now point to Microsoft 365's mail servers, correct? If so, it may take a day or two for the DNS changes to propagate.
My VM-Ware VM running Debian 6 doesn't send emails since I moved to another house with another modem/router. I did a complete reinstall of Debian, but still I can't send email. My network adapter is set to 'Bridged' (with 'Replicate physical network connection state' enabled).
I installed an application that needs to send an email to work properly. But I can't finish it because I don't receive an email at all.
date | mail test#example.com on the command-line also doesn't work, so it hasn't something to do with the application.
Do I need to configure my router in order to send external emails from my VM?
I managed to solve the mailing-problems!
I needed to do two things:
Setting up a SMTP-server for Postfix because my ISP doesn't allow usage of port 25 without using their SMTP-server. See this reference for a how-to.
Then I needed to configure a 'send-from adress', because by default emails are sent from a localhost email adress. The SMTP-server doesn't recognizes this as valid and prevents the email from being sent. See this reference for a how-to.
It cost me almost a few days to solve it, but now I can receive outgoing emails from my Debian system :).
I am using a PHP script for sending emails by IIS 5.1 SMTP.
The emails, go to outbound folder. really path is C:\Inetpub\mailroot\Queue.
after a seconds, it start to send emails properly, but after sending 5 or 6 emails, it stops to send the other ones. SMTP service is still start and it seems there is no problem to SMTP service.
but,If i restart the service, it sends 1 or 2 other emails and then, it stops again.
I mean sending emails stop but service is start.
by the way, emails are stucked in Queue folder.
Also i checked Badmail folder. it is empty
Thanks
are all the emails to the same network? I have seen behaviour like this when the recipient server bans you, yahoo's (xtra) used to do it sometimes to our server in particular. You can check the logs in event viewer for something from the smtp server, you'll find a message from the other server saying something to the effect that you have been temporarily banned, possibly with more detail about why. Trying to connect via telnet also gives you the same message.
When this happens windows will try and send them again later. Restarting the server starts to try sending again and if the ban condition has been lifted messages will flow for a while again until you are rebanned.