Inbound Email Delivery Failures (1000 characters per line)

I've been alerted by folks that some people are sending them email and they are not receiving it.  One would think this would be a simple matter to track down ***IF*** the Message Tracker was working properly (but, unfortunately, its not and we have been waiting quite some time for it to be fixed...)

Anyway, the Message Tracker shows the message coming in, but does not list any scanning state ("Message Details - None" - the usual Message Tracker Failure...).  So, I pull the SMTP logs and start scanning them.  I've noticed on several occasions now that the SMTP log has posted a "500 SMTP connection violates RFC5322 2.1.1 rule of 1000 characters per line.  Fix your mailer." entry associated with the corresponding message.  (To which I might reply "Fix your Effing Message Tracker", but I digress...)

So, I've seen this on several occasions now from several different sources.  These are simply folks trying to send us email and this doesn't appear to be a terribly isolated occurrence. I try to pass this info on to the senders but, as you might expect, they just consider US the source of their problems.  These folks can't do anything about "their mailer".  Many of them don't even know what "mail client" they are running.  At least some of them are running an obscure little email client named OUTLOOK.  I have one customer who simply refuses to send us email anymore and now always calls us instead (Thanks!)...

So, I'm trying to figure out if there is anyway to turn this "feature" off.  Their client doesn't care and my SMTP server (GroupWise) doesn't care.  The only one complaining here is SMG!  There is not a chance in hell I am going to convince the senders to change something on their side ("Fix your mailer") so if we want to get mail from them its now MY problem.  ...and once again, its one of those things that if you don't look for it, you might never know its happening.

I would expect, if we have some way to enable/disable/adjust this check, it should be in the SMTP Interface.  I have found a field labeled "Line Limit" and is set to 1000 but its under "External Delivery" and combined with Relay Server configuration so would appear not be be related to inbound email.  I'm hesitant to TRY any adjustments here as I don't want our site to become yet another one of these violators send email exceeding some RFC line limit... Tsk, Tsk!

Anyone know if its possible to turn this "feature" off or increase it or something so we can receive the associated messages from these scofflaws?

  • Verified Answer


    Domain Management | Expand your domain | SMTP Hosts | very right-hand side next to SMTP host is "Line Limit"



  • Marko, ich changed it to 2000. At some custumers we has 4000, one has 8000.

    This should only be the last resort.
    Primarily, the sender must change its behavior in order to be RFC compliant again. Especially from the point of view of SMTP smuggling, we need to re-evaluate this

  • What doesn't make sense about this is that the line limit error comes not when SMG is receiving the email from the sender, but when SMG transfers the email to GWIA.  What's the point of complaining about an RFC violation in a message you've ALREADY received and accepted, and worse not delivering it?  It's YOUR message now!  That itself could be considered an RFC violation - you told the sender you accepted the message without error, and then you threw it away silently.

  • oh, wait, I might be misunderstanding something... SMG is new to me, so I'm not so literate of SMG's SMTP log yet....

    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [s->g] 220 Ready
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [g->s] EHLO
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [s->g]
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [s->g] 250-8BITMIME
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [s->g] 250-SIZE
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [s->g] 250-DSN
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [s->g] 250 STARTTLS
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [g->s] MAIL FROM:<>
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [s->g] 250 Ok
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [g->s] RCPT TO:<>
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [s->g] 250 Ok
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [g->c] 250 Ok
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [c->g] DATA
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [g->c] 354 Ready to receive data
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> Spooling inbound DATA to: /opt/microfocus/smg/smg-smtp/private/1_11010/temp/~3vb5t7vho0.11g1itv2f97u2k612iorh6.tmp
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> Decoding inbound DATA to: /opt/microfocus/smg/smg-smtp/private/1_11010/temp/~3vb5t7vho0.11h1itv2f97u2k8hv0hj67.tmp
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [g->c] 500 SMTP connection violates RFC5322 2.1.1 rule of 1000 characters per line. Fix your mailer.
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> Processing complete for connection from
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> Processing completed for interface log reference 11010.947

    The line with the RFC line limit violation says [g->c]; is that line coming from GWIA?  

    If GWIA is the one complaining about it, then that is reasonable.... though one wonders why SMG didn't complain when it received the message in the first place.

  • I think SMG is complaining. g (gateway) -> c (client) returns a 500 to the sending client.

    Use "Verified Answers" if your problem/issue has been solved!

  • I deleted my previous posts, because I definitely didn't understand but I think I do now...

    I do believe you're correct that [g->c] is a message from SMG to the sending server (i.e. SMTP client).  What I didn't understand was that SMG is not receiving the email from the SMTP client, completing that transaction and then delivering it to GWIA in a separate transaction; instead it's all happening at once. 

  • Verified Answer

    c = connecting Client
    g = smG server (formerly Gwava, which is what G stood for)
    s = destination Server

    So you are correct, g->c is a line sent from SMG to the connecting client

    SMG works as a proxy.  It transfers commands back and forth between the SMG client and the expected destination SMTP target server.  It does not take ownership of the message.

    It is SMG that is enforcing the default RFC rule as it receives the DATA payload.  If you want to break spec, then you can configure, separately, the line limit accepted by the target servers configured in the domains pages, and also for outbound mail in the SMTP interface settings under 'external delivery'.  Any problems caused by next hop servers enforcing the RFC becomes your responsibility if these are changed.  You can thank Microsoft for making it normal to break that spec.