#164 ASSP drops connection to MTA
OS: Debian 13
ASSP version 2.8.1 SPAM-Eliminator build 24261
A mail was sent to our system, and was terminated after a timeout of the MTA (sQmail) with:
"deferral: TLS_connection/protocol_error_with:.."
In the assp-logs:
Sep-02-26 21:35:05 Connected: session:7F2F64060FA0 xx.xx.xx.67:58862 > xx.xx.xx.8:25 > xx.xx.xx.8:125
Sep-02-26 21:35:05 xx.xx.xx.67 info: got STARTTLS request from xx.xx.xx.67
Sep-02-26 21:35:05 xx.xx.xx.67 support@sender-domain.com info: found message size announcement: 1013.09 kByte
Sep-02-26 21:35:05 [NoProcessing] xx.xx.xx.67 support@sender-domain.com to: info@receiving-customer.com message proxied without processing (except checks enabled for noprocessing mails)
Sep-02-26 21:35:06 xx.xx.xx.67 support@sender-domain.com to: info@receiving-customer.com DKIM-Signature found
Sep-02-26 21:35:06 xx.xx.xx.67 support@sender-domain.com to: info@receiving-customer.com [Plugin] calling plugin ASSP_AFC
Sep-02-26 21:35:06 [MessageOK] xx.xx.xx.67 support@sender-domain.com to: info@receiving-customer.com message ok - (noProcessingIPs) - [test]
Sep-02-26 21:45:06 xx.xx.xx.67 support@sender-domain.com to: info@receiving-customer.com finished message - received DATA size: 1013.26 kByte - sent DATA size: 1.27 kByte
Sep-02-26 21:45:06 xx.xx.xx.67 support@sender-domain.com to: info@receiving-customer.com disconnected: session:7F2F64060FA0 xx.xx.xx.67 - processing time 601 seconds
Then we tried without TLS (we are also in control of sending server)
Same thing again, but then with the MTA reporting:
connection_died._Possible_duplicate!
This happened only to certain mails.
After a lot of debugging we found that the email which had problems was around 1 MB, but contains only 2 very very long lines without a single break.
Adding line-breaks in the long lines resolved the problem.
If we bypassed ASSP totally (connecting to another port directly to the MTA) there was no problem.
So ASSP does something with the long break, resulting that the receiving MTA cannot process the mail.
I'm thinking of something sending "Fragmentation Needed" by ICMP (which would drop the DATA-phase)
However both server have the same MTU (1500) and connected directly with a switch (no router).
We have internally fixed it by bypassing ASSP totally for these sort of emails (they come from an CRM).
But the problem should not exists (or maybe some more logging when a very long line is detected)
Related
https://www.rfc-editor.org/info/rfc5322/#section-2.1.1
https://www.rfc-editor.org/info/rfc5321/#section-4.5.3.1.6
The latest development version 2.8.2 26204 acts smarter on very long lines.
How ever, 998 octets + CRLF is the length limit of a single line.
Change your CRM to act according to the SMTP RFC's and every thing will work like expected.
Thomas
2026-05-13
fixed in assp 2.8.2 SPAM-Eliminator build 26133
change.log
....
"We are currently running ASSP 2.8.2 (build 26034) and have experienced email delivery failures with a "451 Connection timeout" error.
After investigation, we traced the problem to messages containing extremely long lines.
In particular, these emails include a base64-encoded image of approximately 34k characters contained within a single line."
The maximum allowed line length of the SMTP protocol is 1000 byte (incl. [CR][LF]) defined in RFC5321#section-2.3.8 and RFC5322#section-2.1.1
Most mail server will reject such mails - how ever, assp does NOT and let the backend server decide what to do.
ASSP is waiting for a line terminator [LF] before it sends junks to the backend server - this behavior is changed: in case the length
of data waiting to be send exceeds 1000 byte (without a line terminator), this junk is now send to the backend server.
....
Thomas