5
Some messages remain in the spool for hours without even a delivery attempt being made
Problem reported by Gabriele Maoret - SERSIS - 6/1/2020 at 3:26 AM
Submitted
some messages remain in the spool for hours without even a delivery attempt being made and recipients statu in PENDING.

After a while they simply fail.

This si a big issue for our customers


Can you figure out why this is happening?


EG:






23 Replies

Reply to Thread
0
Gabriele Maoret - SERSIS Replied
Restart SmartrMail service and/or reboot the server doesn't solve the issue
1
Thomas Lange Replied
Hi Gabriele,

we are not on build 7454 yet - we are still on 7451.

If I remember right there were issues some month ago with messages in Spool and failing. This was already fixed and in addition more frequent retries for Spool were suggested by support:

Settings / General / Spool - Retry Intervals (Minutes, separated by comma)
1, 1, 5, 5, 15, 30, 30, 30, 30, 60, 90, 120, 240, 480, 960, 1440, 2880

Perhaps this helps for your SmarterMail installation. Otherwise SmarterTools should have a closer look.
0
Gabriele Maoret - SERSIS Replied
Better checking the emails that remain "blocked" in spool I noticed one thing: some of these emails have the NEXT ATTEMPT ("PROSSIMO TENTATIVO" in Italian) set on a time in the past (now here are 12.22).

Could this be the problem?

0
Gabriele Maoret - SERSIS Replied
Am I the only one with this issue?
I'm getting more and more messages that's are for hours in REMOTE DELIVERY state, 0 ATTEMPTS and NEXT ATTEMPT in the past!

Example (actual time 16:51 24H format):



0
Gabriele Maoret - SERSIS Replied
I think i've figured out what's happening:

All the connections that are that state are versus an Aruba SMTP server with IP Address 62.149.157.166

If I try to connet to this IP on port 25 via telnet this is the response:

>>>>>>>>>
421 mxcm01-pc.ad.aruba.it bizsmtp mfA22200r3Uk8nK01 Too many connections, try later.
Connection loosed
>>>>>>>>>

It's seems that SmarterMail doesn't disconnet the SMTP session after that message and never retry again, so the messages remain in the queue forever (or so).


EDIT: another SMTP remote server that cause the same issue: 

62.149.157.151
0
Gabriele Maoret - SERSIS Replied
Similar issue receiving messages...

1
Tim Uzzanti Replied
Employee Post
Please open a ticket and include your delivery logs so we can evaluate.  We don't think there is an issue based on the number of servers we have been on over the last week fine tuning in preparation for release.
Tim Uzzanti
CEO
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Gabriele Maoret - SERSIS Replied
I think you are right, Tim... next days I will investigate further and open a ticket
0
Kyle Kerst Replied
Employee Post
Gabriele I took a quick look at your screenshots and noticed all of these pending deliveries are to Yahoo/Hotmail/etc and this could be a clue as to the root cause. Frequently when we see stalled messages to these providers it is indicative of one of the following:

1. Rate-limiting has been applied to your server IP due to the amount of email coming in from your server. 
2. Mail from your server is being rejected due to failed SPF, RDNS, DKIM, etc from the sending domain.
3. Sending IP address is listed on a blacklist or other spam list such as their internal lists. 

If you search your Delivery logs for these recipients what do you see there? If you could check on these items before submitting a ticket this will help us get to the bottom of it much quicker. Thanks, and have a great day!
Kyle Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Gabriele Maoret - SERSIS Replied
Hi Kyle, can I send the datails to you via PM or do you prefer that I open a ticket first?

P.S.: The destination SMTP servers aren't Yahoo/Hotmail/etc... These are the origination SMTP servers in my latest post that's talking of same issue with INCOMING e-mails... 

With OUTGOING emails the destinations seem to be some ARUBA S.p.A. smtp server, like 62.149.157.166 
2
Grady Werner Replied
Employee Post
Not Kyle, but since he hasn't answered yet, I figured I'd chime in.  We've had instances when using PM for troubleshooting issues that conversations get lost, and that hurts everyone.  We really prefer tickets because there's good oversight to ensure stuff doesn't fall through the cracks.  We realize that sometimes the back and forth of PMs are useful, but tickets ensure accountability and have a significantly higher chance of getting your issue resolved.
Grady Werner
SmarterTools Inc.
www.smartertools.com
1
Gabriele Maoret - SERSIS Replied
OK Grady, I'll open a ticket for this


2
Gabriele Maoret - SERSIS Replied
Before opening a ticket, I thoroughly investigated and perhaps I found the trick...

I found that there are TLS authentication errors in the delivery logs, so I tried to disable the relative option in SETTINGS --> PROTOCOLS --> SMTP OUT:

This seems to have solved the issue, but now I think I have something wrong with my SM certificates setting...

Now I will do a thorough investigation in my configuration, but I ask you politely if anyone has any suggestions to give me on where to look so as not to waste time on unnecessary checks ...


Thanks in advance to all!
0
Sébastien Riccio Replied
Do you have any TLS errors in delivery.log for these delivery attempts, or, is there no attempt at all logged ?

Is there anything else relevant in the delivery log flow for one of the attempt if they exist ?

Sébastien Riccio
System & Network Admin

0
Gabriele Maoret - SERSIS Replied
Hi Sebastian, this is an exeample:  LOG.txt

As you can see in the file, there'are some TLS errors like this:

[2020.06.03] 13:42:22.432 [63750] CMD: STARTTLS
[2020.06.03] 13:42:24.776 [63750] RSP: 220 2.0.0 Ready to start T
[2020.06.03] 13:42:25.510 [63750] Certificate name mismatch. 


The strange thing it's that delay the delivery, but after a while it works...

And it seems to happen only when SM delivery messages to certain SMTP servers, while other servers instead are OK...

Disabling TLS authentication on outbound SMTP solve the issue, but I think that if I can keep it enabled (without issues) it's better...

I need to understand if it's an error in my config or if it's a bug in SM or if are the destination SMTP servers that have issues...

0
Robert G. Replied
I'm having the same results as Gabriele. I'll open a ticket about this as well. It's even happening with users that are on my mail server. user1@domain.com to user2@domain.com getting delayed 20+ minutes Status: "Spam Check". 
0
Scarab Replied
I was having the same problem in Build 7242 but it was maybe 3 or 4 messages a week, so I never really paid it much attention. After upgrading to Build 7459 I was getting 2000 messages an hour that weren't even attempting delivery to local users!

Gabriele, I could kiss you because turning off "Enable TLS if supported by the remote server" fixed it for us immediately (still took a while for the Spool to catch up on a couple hours of messages that accumulated since 2am when we upgraded)!

We have a commercial certificate for our primary domain and a LetsEncrypt certificate for all our other domains. Never had a problem with our certs in SM before, but sure enough we have tons of the "Certificate name mismatch" in the logs.
0
Sébastien Riccio Replied
Hello, the "Certificate name mismatch" could mean that the remote certificate does not match the contacted remote hostname and SM aborts sending the mail using TLS.
If I'm correct, in 7242 it was then retrying without using TLS.

Looks like in mapi-BUILDS it doesn't retry without TLS.

It's maybe a side effect introduced with code changes around this fix:
Fixed: Gateways are using TLS, if available, even though they are configured to use no encryption.

That's only my suppositions.

edit: We don't have this issue but also we  a gateway for relay so the TLS certificate always matches.
Sébastien Riccio
System & Network Admin

0
Gabriele Maoret - SERSIS Replied
Hi Sebastien, so you think it's a BUG in SmarterMail that if it finds out that the REMOTE certificate has an issue, SmarterMail itself doesn't retry without TLS, am I right?
0
Sébastien Riccio Replied
Hello Gabriele, that's a supposition. I remember that previously with 7242 I had every mail delayed mails for 5 minutes (if your spool retry settings are begining with 5 minutes) because our mail gateway had it's certificate expired.
It was trying TLS and failing because of certificate then re-trying after 5 minutes without TLS.

The fact that you have stuck mails forever in the queue if you enable TLS and also got certificates mismatch in the logs makes me think it can be that new builds doesn't retry anymore wihtout TLS, after a failed TLS session. But this would need to be confirmed.

Can you reproduce the issue and check the logs for the stuck messages and see if there is a certificate mismatch error again. If then, can you give me the MX it tries to reach when this errors appears so I can check it's certificate with an openssl command, to confirm that the certificate really mismatches.

Also there should be a little thinking about "should SM retry without TLS if the TLS attempt fail". Because some customers or companies you host can have in their requirements that all mails should be transfered using TLS, or shouldn't be transfered at all.

So a per domain configuration for this should be added, something like "Require TLS for outgoing mails", so that no mails from this customers can be transmitted outsite without a layer of security...

Well that's not the point of this thread... Can you check the remote hostname that triggers the certificate issue?




Sébastien Riccio
System & Network Admin

0
Sébastien Riccio Replied
Gabriele,

I've read the latest log you posted here, it doesn't seems related to the certificate mismatch as the logs shows that it stills sends the mail over the TLS connection.

However, for an unknown reason the session with the server seems to timeout after the DATA command (when the mail content is sent).


[2020.06.03] 13:42:33.214 [63750] CMD: DATA  
[2020.06.03] 13:42:36.026 [63750] RSP: 354 enter mail, end with "." on a line by itself
[2020.06.03] 13:43:36.050 [63750] The smtp session has timed out.
[2020.06.03] 13:43:36.050 [63750] Attempt to ip, '62.149.157.166' success: 'False'

Is it the only destination server having this issue or you have the same with other distant MX ?
(this one is in.9netweb.it)

Kind regards.

Sébastien Riccio
System & Network Admin

0
Gabriele Maoret - SERSIS Replied
No, it's not the only one. This is only an example, there's quite a few other there...

The fact is that if I disable TLS for OUTBAND SMTP the issue suddenly disappear...
0
Robert G. Replied
Our issue was due to URIBLs... The average response time was very high. Oddly enough these were just fine on 7459. It only became an issue after upgrading a few days back. 

Reply to Thread