I’m having a really hard time getting test message to send through the server even though I add a unique Message-ID to each message’s header. It just hangs when I go to send a message that looks like a message that was sent before until it eventually times out. Often, after a timeout of a few minutes I can send that message on the retry.
The messages getting hung up are identical except for the Message-ID and (of course) the new send request. Is it possible that the mail server configuration use in the default MIAB setup is still delaying messages even though they have a unique Message-ID? Why delay and not just reject and report it as a duplicate?
I’m still thinking it is a duplicate issue because I always seam to get new emails through the first time and I did have a good day after adding a unique Message-ID where I saw every message work (maybe it was how I tested it and they did varry though). So, I can’t really be 100% sure. But the client can certainly operate fine and send plenty of messages back-to-back. I’m never dealing with more than 5 messages at a time and I run them one after another until I can get this resolved.
If so, I will have fully testing code and I’m going to want to make sure it only relies on the Message-ID to determinate if a message is unique. Sending the same content of a message at a different time is technically different: it is a different time this event happened.
Why are you adding message ID’s? Normally it is the email client’s job to do so.
I’m writing the email client.
What specific issue are you facing? What errors are you receiving? What are your log entries saying?
Hangs … I’m including the Message-ID in the body of the html message now, light text, small font. I had a few runs where everything sent without hanging and timeouts. It was very unclear this was the issue, there should be a message there. When it first happened, I was glued to the log. There was nothing out of the ordinary there. It should be an easy test though, just sending the same message.
I’ll continue making the message itself unique, that is probably better than expecting all email clients to preserve the Message-ID header.
It seams to be related to my VPN (ivpn). I can by-pass the VPN or run from a VPS and all is fine. IVPN support says they do not block any traffic (SMTP 465 for example) and that because some messages get through it may be MTU related:
It might be related to how your mail server handles incoming traffic.
If some messages are successful, it rules out a restriction on the VPN server’s public IP address.
If the packets are considered too large by the mail server or some network device between your network and our VPN server, packets might be split or fragmented, resulting in twice as many packets as normal. Double the number of packets could result in some manner of blocking by some network hardware, perhaps as a way to stem an “attack” or something that looks suspicious or if the network hardware is not configured to handle fragmented packets.
OpenVPN tends to have better automatic packet size handling, so fragmentation issues are much less common. Consider switching to OpenVPN as a test via the IVPN App’s Settings > Connection area.
Change the packet size by adjusting the MTU for WireGuard connections. Disconnect the VPN, go to the app’s Settings > Connection (Protocol on mobile) area, choose WireGuard, set the MTU to 1412, then reconnect the VPN. If the issue persists, try MTU = 1404, 1396, 1388, 1380, 1372, etc. (keep subtracting 8 to around 1300 if you are inclined to perform so much testing). Clear the MTU field in the Settings > Connection area to reset the MTU back to default (1420).