Re: [mailop] Too many recipients
According to our logs. The first one we saw was at 6:03 this morning and our shipping manager sent an email to two recipients. We did just have it occur with two additional different domains hosted by Outlook.com Is there a whitelist I should be looking to get added back on? Thanks, Job On Wed, Oct 11, 2023, 9:16 AM Job Cacka wrote: > This morning I noticed that many, perhaps all, of the email addresses > hosted by Outlook are only allowing us to send to one recipient at a time. > This is causing our email queue to fill up. > > At first I thought we were sending to too many recipients but several only > had 3 or 4. > > What causes this? How do we get it fixed? > > (Deferred: 452 4.5.3 Too many recipients (AS780090) > > Thanks, > Job > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Too many recipients
This morning I noticed that many, perhaps all, of the email addresses hosted by Outlook are only allowing us to send to one recipient at a time. This is causing our email queue to fill up. At first I thought we were sending to too many recipients but several only had 3 or 4. What causes this? How do we get it fixed? (Deferred: 452 4.5.3 Too many recipients (AS780090) Thanks, Job ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Intermittent slow email delivery
Well, it is good to know the cause of the problem. The reposting wasn't random. I am new to the list and had difficulty sending my first few emails, so I thought I had done something wrong again the first two times. When those two hadn't processed but others were hitting the archive my initial assumption was it was from my end and actually spent 45 minutes looking through my sent items in gmail. That was when I began wondering if there was a problem with gmail. Incidentally, the last was also sent to mailop-ow...@mailop.org because that was what was listed on the web page. For future reference who is on the admin team? Thanks, Job On Wed, Jul 15, 2020 at 8:14 AM Graeme Fowler via mailop wrote: > [admin hat on] > > On 15 Jul 2020, at 15:55, Job Cacka via mailop wrote: > > Sorry for spamming the list guys. > > Take a look at the header information. > > The four copies were sent over a couple of days and you got them when? > > > > Mon Jul 13 16:58:47 BST 2020 > > Mon Jul 13 19:08:50 BST 2020 > > Mon Jul 13 23:36:35 BST 2020 > > Tue Jul 14 19:02:47 BST 2020 > > > > If you only received them on Wednesday then why? > > > > I sent these to the list using a gmail account. I believe gmail has an > intermittent issue. > > The mailop list server had an issue which was resolved this morning. > > Instead of randomly reposting in the hope you can force one through, if > messages aren't appearing then maybe you should try contacting the admin > team - like someone else did, so the issue was fixed. > > As was never actually uttered in the Star Wars canon: "patience, young > padawan"... > > Graeme > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Intermittent slow email delivery
Sorry for spamming the list guys. Take a look at the header information. The four copies were sent over a couple of days and you got them when? *Mon Jul 13 16:58:47 BST 2020* *Mon Jul 13 19:08:50 BST 2020* *Mon Jul 13 23:36:35 BST 2020* *Tue Jul 14 19:02:47 BST 2020* If you only received them on Wednesday then why? I sent these to the list using a gmail account. I believe gmail has an intermittent issue. Thanks, Job On Wed, Jul 15, 2020 at 3:13 AM Laura Atkins wrote: > Hi, Job, > > I’ve seen 4 copies of this message this morning. Things are working here. > > laura > > > > On 13 Jul 2020, at 23:36, Job Cacka via mailop wrote: > > > I am re-submitting thr because it doesn't seem to be showing in the > newsgroup. > > So I spoke a bit too soon on the firewall.This morning I had time to look > at it from a physical and configuration sense. It is a pfSense firewall > that has multiple WAN ports enabled for multiple ISP. The path from the WAN > that contains the MX IPs does not load balance or failover to the other WAN > port. At one time this was setup but was turned off for some reason. > > So NAT/PAT points it to the barracuda. Which in turn passes it to the > proper email server based upon domain or IP address. > > To avoid outbound sending confusion from multiple gateways there is an > Outbound NAT but that shouldn't affect the incoming email as those > connections are from a different source. > > In light of this configuration would it still make sense to have multiple > MX records? One for each WAN/ISP? > > I am considering trying to capture and inspect port 25 as it crosses from > the firewall to the barracuda to see if that will shed light on the > situation. > > Thanks, > Job > > > On Fri, Jul 10, 2020 at 3:56 PM Lukas Tribus wrote: > >> On Fri, 10 Jul 2020 at 23:36, Job Cacka via mailop >> wrote: >> > >> > There is PAT firewall that load balances multiple networks. >> >> Maybe one of those destination networks is unreachable, while others >> are reachable, so when the load-balancing decision points to the >> unreachable network, the TCP session will not establish? Have you >> verified connectivity of each and every backend server from your >> load-balancers perspective? >> >> Using multiple MX records, one for each destination mailserver would >> be the better setup, as opposed to load-balancing incoming port 25 >> traffic (probably without appropriate health-checking and logging) of >> a single MX record. >> >> >> cheers, >> lukas >> > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > -- > Having an Email Crisis? We can help! 800 823-9674 > > Laura Atkins > Word to the Wise > la...@wordtothewise.com > (650) 437-0741 > > Email Delivery Blog: https://wordtothewise.com/blog > > > > > > > > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Fwd: Intermittent slow email delivery
I am re-submitting thr because it doesn't seem to be showing in the newsgroup. So I spoke a bit too soon on the firewall.This morning I had time to look at it from a physical and configuration sense. It is a pfSense firewall that has multiple WAN ports enabled for multiple ISP. The path from the WAN that contains the MX IPs does not load balance or failover to the other WAN port. At one time this was setup but was turned off for some reason. So NAT/PAT points it to the barracuda. Which in turn passes it to the proper email server based upon domain or IP address. To avoid outbound sending confusion from multiple gateways there is an Outbound NAT but that shouldn't affect the incoming email as those connections are from a different source. In light of this configuration would it still make sense to have multiple MX records? One for each WAN/ISP? I am considering trying to capture and inspect port 25 as it crosses from the firewall to the barracuda to see if that will shed light on the situation. Thanks, Job On Fri, Jul 10, 2020 at 3:56 PM Lukas Tribus wrote: > On Fri, 10 Jul 2020 at 23:36, Job Cacka via mailop > wrote: > > > > There is PAT firewall that load balances multiple networks. > > Maybe one of those destination networks is unreachable, while others > are reachable, so when the load-balancing decision points to the > unreachable network, the TCP session will not establish? Have you > verified connectivity of each and every backend server from your > load-balancers perspective? > > Using multiple MX records, one for each destination mailserver would > be the better setup, as opposed to load-balancing incoming port 25 > traffic (probably without appropriate health-checking and logging) of > a single MX record. > > > cheers, > lukas > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Intermittent slow email delivery
Perhaps this original message is still stuck in some queue? I wrote it yesterday and it never made it through to the list. At least it isn't in the archive so try again. So I spoke a bit too soon on the firewall last week. Monday morning I had time to look at it from a physical and configuration sense. It is a pfSense firewall that has multiple WAN ports enabled for multiple ISP. The path from the WAN that contains the MX IPs does not load balance or failover to the other WAN port. At one time this was setup but was turned off because some prtotocols don't failover well. So NAT/PAT points it to the barracuda. Which in turn passes it to the proper email server based upon domain or IP address. To avoid outbound sending confusion from multiple gateways there is an Outbound NAT but that shouldn't affect the incoming email as those connections are from a different source. In light of this configuration would it still make sense to have multiple MX records? One for each WAN/ISP? I am considering trying to capture and inspect port 25 as it crosses from the firewall to the barracuda to see if that will shed light on the situation. Also, I am curious if these failed attempts could be related to DNS issues. All my checks on DNS this far have been ok. And little to nothing has changed in that regard in the last 7 or 8 weeks. Historically we don't use or support TLS and perhaps that is the cause. I know in the last 4-5 years this climate has dramatically changed. Thanks, Job On Fri, Jul 10, 2020 at 5:24 PM Ángel via mailop wrote: > On 2020-07-10 at 14:36 -0700, Job Cacka wrote: > > There is PAT firewall that load balances multiple networks. > > A Barracuda spam filter > > And then the MX server. > > > > > > It was working well until about 6-8 weeks ago when we began to notice > > the intermittent issue. > > > > > > Thanks, > > Job > > I would have a look at that firewall. Is is possible that it may be > trying to load balance with a missing host? > > I see that 50% of the connection attempts, the SYN receives RST,ACK > while the other 50% the expected SYN,ACK.¹ > > For the record, the TTL of the SYN,ACK is two units bigger than the one > of the RST,ACK ones. > > > Best regards > > > > ¹ not the *same* ones, but of a block of 16, as produced by > tcptraceroute, I'm seeing a consistent split of 8/8 > > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Intermittent slow email delivery
Probably because of the reply all gmail requires. It wasn't hitting mailop@mailop.org. On Mon, Jul 13, 2020 at 11:15 AM Luis E. Muñoz wrote: > > > On 13 Jul 2020, at 11:08, Job Cacka wrote: > > > This didn't go through two hours ago from my gmail account. > > I saw it two hours ago. > > Best regards > > -lem > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Intermittent slow email delivery
This didn't go through two hours ago from my gmail account. So I spoke a bit too soon on the firewall.This morning I had time to look at it from a physical and configuration sense. It is a pfSense firewall that has multiple WAN ports enabled for multiple ISP. The path from the WAN that contains the MX IPs does not load balance or failover to the other WAN port. At one time this was setup but was turned off for some reason. So NAT/PAT points it to the barracuda. Which in turn passes it to the proper email server based upon domain or IP address. To avoid outbound sending confusion from multiple gateways there is an Outbound NAT but that shouldn't affect the incoming email as those connections are from a different source. In light of this configuration would it still make sense to have multiple MX records? One for each WAN/ISP? I am considering trying to capture and inspect port 25 as it crosses from the firewall to the barracuda to see if that will shed light on the situation. Thanks, Job On Mon, Jul 13, 2020 at 8:58 AM Job Cacka wrote: > So I spoke a bit too soon on the firewall.This morning I had time to look > at it from a physical and configuration sense. It is a pfSense firewall > that has multiple WAN ports enabled for multiple ISP. The path from the WAN > that contains the MX IPs does not load balance or failover to the other WAN > port. At one time this was setup but was turned off for some reason. > > So NAT/PAT points it to the barracuda. Which in turn passes it to the > proper email server based upon domain or IP address. > > To avoid outbound sending confusion from multiple gateways there is an > Outbound NAT but that shouldn't affect the incoming email as those > connections are from a different source. > > In light of this configuration would it still make sense to have multiple > MX records? One for each WAN/ISP? > > I am considering trying to capture and inspect port 25 as it crosses from > the firewall to the barracuda to see if that will shed light on the > situation. > > Thanks, > Job > > > > > > On Fri, Jul 10, 2020 at 3:56 PM Lukas Tribus wrote: > >> On Fri, 10 Jul 2020 at 23:36, Job Cacka via mailop >> wrote: >> > >> > There is PAT firewall that load balances multiple networks. >> >> Maybe one of those destination networks is unreachable, while others >> are reachable, so when the load-balancing decision points to the >> unreachable network, the TCP session will not establish? Have you >> verified connectivity of each and every backend server from your >> load-balancers perspective? >> >> Using multiple MX records, one for each destination mailserver would >> be the better setup, as opposed to load-balancing incoming port 25 >> traffic (probably without appropriate health-checking and logging) of >> a single MX record. >> >> >> cheers, >> lukas >> > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Intermittent slow email delivery
So I spoke a bit too soon on the firewall.This morning I had time to look at it from a physical and configuration sense. It is a pfSense firewall that has multiple WAN ports enabled for multiple ISP. The path from the WAN that contains the MX IPs does not load balance or failover to the other WAN port. At one time this was setup but was turned off for some reason. So NAT/PAT points it to the barracuda. Which in turn passes it to the proper email server based upon domain or IP address. To avoid outbound sending confusion from multiple gateways there is an Outbound NAT but that shouldn't affect the incoming email as those connections are from a different source. In light of this configuration would it still make sense to have multiple MX records? One for each WAN/ISP? I am considering trying to capture and inspect port 25 as it crosses from the firewall to the barracuda to see if that will shed light on the situation. Thanks, Job On Fri, Jul 10, 2020 at 3:56 PM Lukas Tribus wrote: > On Fri, 10 Jul 2020 at 23:36, Job Cacka via mailop > wrote: > > > > There is PAT firewall that load balances multiple networks. > > Maybe one of those destination networks is unreachable, while others > are reachable, so when the load-balancing decision points to the > unreachable network, the TCP session will not establish? Have you > verified connectivity of each and every backend server from your > load-balancers perspective? > > Using multiple MX records, one for each destination mailserver would > be the better setup, as opposed to load-balancing incoming port 25 > traffic (probably without appropriate health-checking and logging) of > a single MX record. > > > cheers, > lukas > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Intermittent slow email delivery
I checked my ISP and they wrap it in a vlan and hand it off to us, so that is fine. On the firewall I noticed several high volume rules that were logging since 2018 and turned them off in case it was causing an issue. Looking at PAT/NAT we are translating in bound and outbound traffic so that should be ok. I go over the Barracuda next week with a fine tooth comb. Thanks, Job On Fri, Jul 10, 2020, 3:01 PM Jay Hennigan via mailop wrote: > On 7/10/20 14:36, Job Cacka via mailop wrote: > > There is PAT firewall that load balances multiple networks. > > This is a possibility, especially if the load-balancing is pushing some > incoming traffic to the wrong internal network. > > > A Barracuda spam filter > > If this is configured to drop traffic based on originating IP, it could > be the problem, especially if it's using blacklists that change rapidly > or if it is configured to deny connections when it can't successfully > phone home to evaluate them. > > > And then the MX server. > > This is doubtful as the Barracuda is what is opening the socket based on > the banner on Adam's test. > > > It was working well until about 6-8 weeks ago when we began to notice > > the intermittent issue. > > What configuration changes were made around that time? > > -- > Jay Hennigan - j...@west.net > Network Engineering - CCIE #7880 > 503 897-8550 - WB6RDV > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Intermittent slow email delivery
There is PAT firewall that load balances multiple networks. A Barracuda spam filter And then the MX server. It was working well until about 6-8 weeks ago when we began to notice the intermittent issue. Thanks, Job On Fri, Jul 10, 2020, 12:30 PM Luis E. Muñoz via mailop wrote: > On 10 Jul 2020, at 9:47, Adam D. Barratt via mailop wrote: > > On Fri, 2020-07-10 at 09:22 -0700, Job Cacka via mailop wrote: > > slowmailtest...@ccbox.com > slowmailtest...@ccbox.com > > slowmailtest...@p-r-c.com > slowmailtest...@p-r-c.com > > From a quick test, at least half of connections get immediately > rejected, which probably isn't helping: > > Seeing the same results from Amsterdam, New York, California, Oregon and > London. > > A trace gets up to > > static-76-14-192-30.or.wavecable.com (76.14.192.30) 77.015 ms 76.805 ms > 77.570 ms > > Are there load balancers or NAT devices in front of those MXen? I can see > that MXen and IPs remain unchanged since at least October 2019 – was this > happening back then? > > Best regards > > -lem > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Intermittent slow email delivery
Right. So where should I begin? Firewall says it passes all traffic. Next would be Barracuda it doesn't show any drops. I suppose on the server I could look at tcpdump. Thanks! Job On Fri, Jul 10, 2020, 11:26 AM Jay Hennigan via mailop wrote: > On 7/10/20 11:06, Job Cacka via mailop wrote: > > "Senders will tend to back off, and retry at increasingly long > > intervals, until they get a successful connection." > > > > Thanks for the test Adam. I do agree with your Analysis. The interesting > > thing is I am not seeing this refusal at my end logged. Perhaps it never > > made it to the maillog and that is how I am missing it. > > It's not going to make it to your mail log. The connection is being > refused at the TCP level. > > -- > Jay Hennigan - j...@west.net > Network Engineering - CCIE #7880 > 503 897-8550 - WB6RDV > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Intermittent slow email delivery
"Senders will tend to back off, and retry at increasingly long intervals, until they get a successful connection." Thanks for the test Adam. I do agree with your Analysis. The interesting thing is I am not seeing this refusal at my end logged. Perhaps it never made it to the maillog and that is how I am missing it. I do see the message to my other server. It came through fine. Did you send them both the same way? Thanks, Job On Fri, Jul 10, 2020, 9:58 AM Adam D. Barratt via mailop wrote: > On Fri, 2020-07-10 at 09:22 -0700, Job Cacka via mailop wrote: > > slowmailtest...@ccbox.com > > slowmailtest...@ccbox.com > > > > slowmailtest...@p-r-c.com > > slowmailtest...@p-r-c.com > > From a quick test, at least half of connections get immediately > rejected, which probably isn't helping: > > adam@kotick:$ telnet prcmail.p-r-c.com 25 > Trying 76.14.210.251... > telnet: Unable to connect to remote host: Connection refused > adam@kotick:$ telnet prcmail.p-r-c.com 25 > Trying 76.14.210.251... > telnet: Unable to connect to remote host: Connection refused > adam@kotick:$ telnet prcmail.p-r-c.com 25 > Trying 76.14.210.251... > Connected to prcmail.p-r-c.com. > Escape character is '^]'. > 220 barracuda.ccbox.com ESMTP (f191c7be2ab0eba84da576b7c6e04258) > quit > 221 barracuda.ccbox.com Goodbye adsl.funky-badger.org, closing connection > Connection closed by foreign host. > > Testing using swaks also gave refusals for the first two attempts. > > Senders will tend to back off, and retry at increasingly long > intervals, until they get a successful connection. > > Adam > > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Intermittent slow email delivery
Hmmm, for some reason I need to "Reply All" in Gmail to reply to the list. Try two. "You have no logs, and provide little to no detail." Correct, and if it wasn’t a problem I wouldn’t even see the issue. I only have a few message headers to go off of because the sender is experiencing the “temporary” error. However the header doesn’t lie. Especially when comparing the header to what is known outside the header log. When the header agrees with experiential data it is a convincing argument. "You tried to contact with those organizations, but you were fruitless. It's almost impossible to figure out what happens to people on this mailing list. I would suggest a couple of strategies: First, you disclose the actual domain and provide a couple of test mailboxes, so that people here that may be willing to have a look to *your* problem can at least check if from their side the dns is ok, if your primary MX is broken, if their clients provide the same abnormal behavior when mailing those mails, etc." I did not provide all of that information previously because I didn’t think of a good way to do that and limit future spam. Thankyou for this wise suggestion. I have created two test aliases per domain we operate. I did it this way since we commonly see the problem when an email is sent to two recipients simultaneously, although users are keyed to the issue and now it seems to be noticed at other crucial times. slowmailtest...@ccbox.com slowmailtest...@ccbox.com slowmailtest...@p-r-c.com slowmailtest...@p-r-c.com "Second option. You involve your customer on this investigation. - The email issue caused a damage to your customer. - Your customer is not using "gmail", but a business version of it. - From your point of view, it is gmail's fault, since it didn't deliver the email to you until 19 hours later (although we can guess that the real problem will be somewhere in your setup, since it's not just gmail failing to properly deliver on time). - Thus you get your customer to open a ticket with gmail on why they took 19 hours to deliver their email. This is the same question you wanted gmail to answer you, but asked by a paying gmail customer that suffered its consequences. I expect that Google will be able to provide ample justification on *why* their systems were unable to deliver it earlier (e.g. they tried to connect from a dozen ip address, but were unable since -after you investigate- your firewall was any dropping packets from most of their outgoing servers). Once you get the actual view of the delay from their side, you should be able to progress towards fixing it." Yes, I agree this is the preferred strategy. My experience thus far has been either the organization was too large to properly care. A clear and present problem in today’s corporate America. Or the organization is too small (which was the case this week) to figure out how to do anything about it. As I keep working through the problem I will eventually come to the right combination and bear some fruit from my efforts. This is also why I posted this here. Thanks, Job Cacka On Thu, Jul 9, 2020, 6:13 PM Ángel via mailop wrote: > On 2020-07-09 at 12:46 -0700, Job Cacka wrote: > > If you work with one of these relays and can shed light on the delay I > > would love to know how to get it fixed. > > > You have no logs, and provide little to no detail. You tried to contact > with those organizations, but you were fruitless. It's almost impossible > to figure out what happens to people on this mailing list. > > I would suggest a couple of strategies: > > First, you disclose the actual domain and provide a couple of test > mailboxes, so that people here that may be willing to have a look to > *your* problem can at least check if from their side the dns is ok, if > your primary MX is broken, if their clients provide the same abnormal > behavior when mailing those mails, etc. > > > Second option. You involve your customer on this investigation. > > - The email issue caused a damage to your customer. > - Your customer is not using "gmail", but a business version of it. > - From your point of view, it is gmail's fault, since it didn't deliver > the email to you until 19 hours later (although we can guess that the > real problem will be somewhere in your setup, since it's not just gmail > failing to properly deliver on time). > - Thus you get your customer to open a ticket with gmail on why they > took 19 hours to deliver their email. This is the same question you > wanted gmail to answer you, but asked by a paying gmail customer that > suffered its consequences. > I expect that Google will be able to provide ample justification on > *why* their systems were unable to deliver it earlier (e.g. they tried > to connect from a dozen ip address, but were unable since -after you > investigate- your firewall was any dropping packets from most of their > outgoing servers). > > Once you get the actual view of the
[mailop] Intermittent slow email delivery
For the last several weeks I have been tracking slow email from several sources. When it is easiest to see is when an outside source will send an email to two or more of our employees at the same time. One email copy to one person will show up right away and the other might be several hours later. Often we have had one employee reply all to the message and the other employee will notice they didn’t get that part of the email thread as the Reply All is received before the original. Looking at the logs on our end show nothing. No attempt for that message at the time it was originally sent. Investigating email headers when it finally arrives reveals the message’s path and it sat for a long time at the senders’ last email server in the list. These servers usually are some third party relay and have included google.com, outlook.com, iphmx.com, cudaops.com, mimecast.com and probably more that I haven’t found yet. If you work with one of these relays and can shed light on the delay I would love to know how to get it fixed. If you have examples of this you have been tracking in the last month and a half or so I would like to hear about what you have discovered. I have asked several of the other sending organizations for email logs and error messages but have not had any usable response. I did look at the possibility of incoming greylisting. Our Barracuda does not support it and it is not enabled. Also, if this was the issue the Barracuda should make some log entry that the email was delayed. We created a support ticket with Barracuda and came up with no log entries prior to when it was received. It was like it sat in a queue for many hours. I also took the time to ensure these senders were in our whitelist and that did not help either. Because it is intermittent and eventually arrives I think I can rule out most routing issues and I did double check DNS but see no changes there. Yesterday: One of our customers sent us an email asking us to cancel a delivery about 8am yesterday. We received the email 19 hours later and they got the product they didn't need about 3 hours after the email left the client's system. The customer uses Gmail to provide backend email services. See attached screenshot of header analysis. Thanks in advance, Job ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Intermittent slow email delivery
For the last several weeks I have been tracking slow email from several sources. When it is easiest to see is when an outside source will send an email to two or more of our employees at the same time. One email copy to one person will show up right away and the other might be several hours later. Often we have had one employee reply all to the message and the other employee will notice they didn’t get that part of the email thread as the Reply All is received before the original. Looking at the logs on our end show nothing. No attempt for that message at the time it was originally sent. Investigating email headers when it finally arrives reveals the message’s path and it sat for a long time at the senders’ last email server in the list. These servers usually are some third party relay and have included google.com, outlook.com, iphmx.com, cudaops.com, mimecast.com and probably more that I haven’t found yet. If you work with one of these relays and can shed light on the delay I would love to know how to get it fixed. If you have examples of this you have been tracking in the last month and a half or so I would like to hear about what you have discovered. I have asked several of the other sending organizations for email logs and error messages but have not had any usable response. I did look at the possibility of incoming greylisting. Our Barracuda does not support it and it is not enabled. Also, if this was the issue the Barracuda should make some log entry that the email was delayed. We created a support ticket with Barracuda and came up with no log entries prior to when it was received. It was like it sat in a queue for many hours. I also took the time to ensure these senders were in our whitelist and that did not help either. Because it is intermittent and eventually arrives I think I can rule out most routing issues and I did double check DNS but see no changes there. Thanks in advance, Job ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
