Verified Answers

If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it! Learn more

  • State Verified Answer
  • Replies replies
    11
  • Subscribers subscribers
    11
  • Views views
    1187
  • Users 0 members are here
  • +1 person also asked this people also asked this
Related
Options

Inbound Email Delivery Failures (1000 characters per line)

evanevery

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

    +1

    Hello,

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

    Cheers,

    Laura

  • 0 in reply to 

    Thanks!  I'll give that a shot!

  • 0 in reply to 

    That saved my day  :-)

    Thank you  

  • 0 in reply to 

    Thomas, what did you change the value to ?

  • 0 in reply to 

    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

  • 0 in reply to 

    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.

  • 0 in reply to 

    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 mail.mydomain.com Ready
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [g->s] EHLO o2.mail.orginalsenderdomain.com
    [140022284011264] 2024-02-28 11:30:49 (SMTP)<947> [s->g] 250-mail.mydomain.com
    [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:<bounces+37059-473c-dave=recipeintdomain.com@mail.originalsender.com>
    [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:<dave@recipientdomain.com>
    [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 167.89.34.13
    [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.

  • 0   in reply to 

    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!

  • 0 in reply to   

    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

    +1   in reply to 

    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.

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.