I create a topic, make its announcement. Error messages are received:
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[email protected]
message has lines too long for transport
Reporting-MTA: dns;
Action: failed
Final-Recipient: rfc822;[email protected]
Status: 5.0.0
Return-path: <[email protected]>
Received: from
by with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384
(Exim 4.96)
(envelope-from <[email protected]>)
id 1sPjpY-009nPp-38
for [email protected];
Fri, 05 Jul 2024 16:22:32 +0200
Subject: =?UTF-8?B?0J3QvtCy0LUg0L7Qs9C+0LvQvtGI0LXQvdC90Y86IMKr0J/QvtGB0YIg0JLQvtGA0YHQutC70LDCuyDQsiDQvtC90L7QstC70LXQvdC+0LzRgyDRgdGC0LDRgNC+0LzRgyDRhNC+0YDQvNCw0YLRlg==?=
To: <[email protected]>
From: "=?UTF-8?B?0J/QvtGB0YIg0JLQvtGA0YHQutC70LA=?=" <[email protected]>
Date: Fri, 05 Jul 2024 14:22:00 -0000
X-Mailer: SMF
Mime-Version: 1.0
content-type: multipart/alternative; boundary="SMF-0d3a8566d103b202f02888da4addd717"
content-transfer-encoding: 7bit
Message-Id: <[email protected]>
X-Exim-DSN-Information: Due to administrative limits only headers are returned
???
Smf version?
Mods installed?
What email protocol are you using? Smtp or phpmail?
Are you pasting these messages jnto smf from an offline editor?
https://www.webfulcreations.com/how-to-resolve-message-has-lines-too-long-for-transport-error/
SMF 2.1.4, SMTP.
I do not paste from the offline editor. I create a new topic, check "Announce a topic", instead of delivering an announcement about the topic to users, I get the above error.
All other mail - test, mailing, notification of reply in the subject works correctly.
Also tried to increase
ALTER TABLE smf_mail_queue MODIFY COLUMN subject VARCHAR(600);
gradually increased to 5000, no effect.
The problem has nothing to do with the smf database... it's thr mail client/mail recipient
Mods?
TinyPortal
Ad Management Mod
Alternate User Posting
BBC
BBC Message Boxes
FancyBox 4 SMF
HtmlButton
Merge Double Posts
Optimus
Post Subject Length
Quick Spoiler
StickyTopicsOrder
Those messages are received in the email client, correct?
That's typically an email client issue - for the recipient. Not really an SMF issue.
Viewing the raw message might help understand it better. Some things are under your control - eg., subject length.
Why is the mail client here, how does the server send me a message that the topic announcement was not delivered to the user due to such and such errors?
The above message was sent to you by
[email protected].
So the message was sent out successfully by smf, but that particular mail transport for one or more recipients didn't like it, and responded, and told you why.
Yup... what was the subject/title of the post?
By using the mod to make post titles longer, you exceed the 78 character limit enforced by Gmail
So,as stated.. the email RECIPIENT mailbox is rejecting the message and tells your server why
I returned the standard value of 80 characters in the mod settings. The test gave the same result, with the same error.
In addition, sending messages about new answers, mailing works. Only announcements do not work. So, it is not a matter of fashion, which increases the title of the topic.
Php version?
If gmail is the recipient, I believe there were some issues with gmail not liking email sent by php 8.0.x...
If on 8.0, I'd try php 8.1 or 8.2, or even 7.4.
I have a vague recollection of something about line endings changed in php8+...
The error comes from GMail, specifically because GMail rejects any emails containing lines over 78 characters, as per RFC 2822.
Let's reduce everything to a heap.
SMF 2.1.4, SMTP, PHP 8.1.6.
1. I create a topic, check "Announce a topic", save the topic. Instead of announcing the topic to users, I get error messages: You cannot view this attachment. You cannot view this attachment. You cannot view this attachment. I specially provide files of error reports from various postal services - that is, it is not a matter of gmail.
2. When replying in the same topic, the message about a new reply comes normally.
3. Removed the Post Subject Length modification altogether. I protested the announcement of the topic - there is an error.
Quote from: Aleksi on July 05, 2024, 12:28:15 PMThe error comes from GMail, specifically because GMail rejects any emails containing lines over 78 characters, as per RFC 2822.
Good, but the messages about the answer in the same topic, the announcement of which GMail swears, come regularly.
Then look in more detail in to what is different about those messages?
For some reason, one has lines over 78 characters, other apparently does not.
Here is the body of the reply message in the same thread, which was delivered successfully.
Delivered-To: [email protected]
Received: by 2002:a05:6359:7b18:b0:1aa:b21e:4715 with SMTP id wk24csp170339rwc;
Fri, 5 Jul 2024 08:24:47 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IE4QtrlQWQCNSB0YZBDVo7UCdXOwJ5ScQPHagz1nLc2k6btxLiJRH5zFp5fvdKJKQtoPPHD
X-Received: by 2002:ac2:46db:0:b0:52c:dea8:7ca0 with SMTP id 2adb3069b0e04-52ea06b7384mr3374203e87.55.1720193087476;
Fri, 05 Jul 2024 08:24:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1720193087; cv=none;
d=google.com; s=arc-20160816;
b=KtlBAimiBw+onrc4jOsZyp13r+18RVVL0cz0ImFTjkqV77cv+KwLpyALHq/w9brsRY
capj+NXqWmmWPLl3lB7NKj5eHMUYN+hjEkH2R8AZ6luLGkHycUmvByfJU6hHVFbUoU+O
8mM9F5voQnyaAEuOG8LttYLkvScnNfQrL4gDKJEkQgvgf/2EuC3aOn2loPUssz7/sszY
pxjyqookma9wFv8oEeI4dipwTLUErxaF8wKD0wtPMF0CFkIPfnPWGbimM/PMqG6cEUPR
fxaICe/u1xk0gIw5FbO5l28xUrkl+xMzRiJqnJdnpaQYYwWncybmIU1/4pJbRzYrr+fN
kvoQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=content-transfer-encoding:mime-version:message-id:date:from:to
:subject:dkim-signature;
bh=Y+p95cURxnjJguruciKK/HWECUW1tvTBQAkyRWvMu8o=;
fh=fkz5j1HuCqnupPsCmCcR7ndLlOzGlpekzq8rFp/9Hhc=;
b=EHhv5kk2r/9VfjAHzpSg47d7CPhPRtQw67R8aDzpFV/FRcnFcTcUkntDzOzUZy/fgH
aLN7TVVnWkFmt9f54yff0z7Osprcp9SdKeco47GjDvhxWfPgAhSG+VjWFt6TjRkm7Gm/
3h2v/3Z13TEJTEruJA+9sDgfi+wrEHWWl40eJqLLtGKB0krJWexk1UXzCXltl5+4wo08
A9JNNVt8nNE1BHcVlujmQFxrwiPpFeqwrTgK128ubmKyAFdin58V75pLfD7LN39BTVG4
pwKdxO4NxInrQC/6S+eWuHNxFlBgHX2fUEcjwno1eZ2XQ75JctgjZauCOoKPtPRc5eCy
ulgg==;
dara=google.com
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass [email protected] header.s=dkim header.b=ciyx+rh+;
spf=pass (google.com: domain of [email protected] designates 95.215.157.210 as permitted sender) [email protected];
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=postvorskla.pp.ua
Return-Path: <[email protected]>
Received: from ova.in.ua (ova.in.ua. [95.215.157.210])
by mx.google.com with ESMTPS id 2adb3069b0e04-52e7f233cc1si4515892e87.284.2024.07.05.08.24.46
for <[email protected]>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 05 Jul 2024 08:24:47 -0700 (PDT)
Received-SPF: pass (google.com: domain of [email protected] designates 95.215.157.210 as permitted sender) client-ip=95.215.157.210;
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=dkim header.b=ciyx+rh+;
spf=pass (google.com: domain of [email protected] designates 95.215.157.210 as permitted sender) [email protected];
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=postvorskla.pp.ua
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=postvorskla.pp.ua; s=dkim; h=content-transfer-encoding:content-type:
Mime-Version:Message-ID:Date:From:To:Subject:Sender:Reply-To:Cc:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=Y+p95cURxnjJguruciKK/HWECUW1tvTBQAkyRWvMu8o=; b=ciyx+rh+oyR8ZsBHgFHtRSFjbK
irGds7H8nwtWHCVtv+6G6ihj+xbDLkfkhxnwSiKAOJ8sdLrsL+0eQvUhcs0Ccbwm8GLyPVV+fyAKV
yzIabZ7Thv3FA++seUc/IXpo+AwcYD/4WZUVfQzMr47TSR8F1q97uLwt/vLsvxem3kY0=;
Received: from ova.in.ua ([95.215.157.210]:60160)
by ova.in.ua with esmtpa (Exim 4.96)
(envelope-from <[email protected]>)
id 1sPknl-00Gurg-2R
for [email protected];
Fri, 05 Jul 2024 17:24:45 +0200
Subject: =?UTF-8?B?0JLRltC00L/QvtCy0ZbQtNGMINGDINGC0LXQvNGWOiBSZTogwqvQn9C+0YHRgiDQktC+0YDRgdC60LvQsMK7INCyINC+0L3QvtCy0LvQtdC90L7QvNGDINGB0YLQsNGA0L7QvNGDINGE0L7RgNC80LDRgtGW?=
To: <[email protected]>
From: "=?UTF-8?B?0J/QvtGB0YIg0JLQvtGA0YHQutC70LA=?=" <[email protected]>
Date: Fri, 05 Jul 2024 15:24:20 -0000
Message-ID: <[email protected]>
X-Mailer: SMF
Mime-Version: 1.0
content-type: multipart/alternative; boundary="SMF-008e098c2bf26f4af78bba6b4d63defb"
content-transfer-encoding: 7bit
У темі, за якою ви стежите, була опублікована відповідь від Тест.
Переглянути відповідь: https://postvorskla.pp.ua/index.php?topic=1059.new#new
Відписатися від цієї теми можна за цим посиланням: https://postvorskla.pp.ua/index.php?action=notifytopic;topic=1059;sa=off;u=2;token=K3foh44qrzcBBA
У цій темі можуть бути розміщені інші відповіді, але ви не отримаєте більше сповіщень, доки не відвідаєте її.
З повагою,
Команда Пост Ворскла.
--SMF-008e098c2bf26f4af78bba6b4d63defb
content-type: text/plain; charset=UTF-8
content-transfer-encoding: base64
0KMg0YLQtdC80ZYsINC30LAg0Y/QutC+0Y4g0LLQuCDRgdGC0LXQttC40YLQtSwg0LHRg9C70LAg
0L7Qv9GD0LHQu9GW0LrQvtCy0LDQvdCwINCy0ZbQtNC/0L7QstGW0LTRjCDQstGW0LQg0KLQtdGB
0YIuDQoNCtCf0LXRgNC10LPQu9GP0L3Rg9GC0Lgg0LLRltC00L/QvtCy0ZbQtNGMOiBodHRwczov
L3Bvc3R2b3Jza2xhLnBwLnVhL2luZGV4LnBocD90b3BpYz0xMDU5Lm5ldyNuZXcNCg0K0JLRltC0
0L/QuNGB0LDRgtC40YHRjyDQstGW0LQg0YbRltGU0Zcg0YLQtdC80Lgg0LzQvtC20L3QsCDQt9Cw
INGG0LjQvCDQv9C+0YHQuNC70LDQvdC90Y/QvDogaHR0cHM6Ly9wb3N0dm9yc2tsYS5wcC51YS9p
bmRleC5waHA/YWN0aW9uPW5vdGlmeXRvcGljO3RvcGljPTEwNTk7c2E9b2ZmO3U9Mjt0b2tlbj1L
M2ZvaDQ0cXJ6Y0JCQQ0KDQrQoyDRhtGW0Lkg0YLQtdC80ZYg0LzQvtC20YPRgtGMINCx0YPRgtC4
INGA0L7Qt9C80ZbRidC10L3RliDRltC90YjRliDQstGW0LTQv9C+0LLRltC00ZYsINCw0LvQtSDQ
stC4INC90LUg0L7RgtGA0LjQvNCw0ZTRgtC1INCx0ZbQu9GM0YjQtSDRgdC/0L7QstGW0YnQtdC9
0YwsINC00L7QutC4INC90LUg0LLRltC00LLRltC00LDRlNGC0LUg0ZfRly4NCg0K0Jcg0L/QvtCy
0LDQs9C+0Y4sDQrQmtC+0LzQsNC90LTQsCDQn9C+0YHRgiDQktC+0YDRgdC60LvQsC4=
--SMF-008e098c2bf26f4af78bba6b4d63defb--
My guess looks like the 7bit encoding is too long per line.
There are definitely risks on long subjects where the "Re: " or "Announcement: " is added (or both), that the line is pushed over the limit... Unfortunately that means the subject must be kinda short, because all that eats into your 78 characters.
E.g.: Відповідь у темі: Re: «Пост Ворскла» в оновленому старому форматі
vs: Нове оголошення: «Пост Ворскла» в оновленому старому форматі
So, dear ones, we did not dig there. The mail server does not curse at the title of the topic, but at the text in the first topic of the topic that is announced, because a certain part of it is included in the message.
Question: how to fix it?
The easiest option is not to include part of the text from the first topic of the topic in the announcement at all. Where and how can it be done?
We are fixing the topic announcement error. In the /Themes/default/languages/EmailTemplates.ХXХ.php file, edit the block from line 193 by removing the {MESSAGE} variable from the email template.
I spent some time trying to reproduce this, & couldn't. My initial thoughts above were that some contraints were exceeded due to the insertion of "New Announcment" in the subject. But I couldn't reproduce that in SMF. The subject remained properly intact & was sent to my test gmail account properly.
I also made a 20000 character, single-line post in Cyrillic, then announced it... That also went out fine & was received properly by gmail.
But what stands out above is that there is a portion of the email that was treated as 7-bit and entity encoded, and not base64 encoded. I suspect both Kindred & vbgamer45 were on the right track... There is *something* in that text that triggered special processing.
None of my attempts produced that behavior, it was all base64 encoded, and sent and received properly by gmail.
I am not familiar enough with that code to understand what would trigger entity encoding vs base64. I may look again over the weekend.
Interesting problem.
Might also check out exim mailserver settings. google and look at error messages
Quote from: shawnb61 on July 05, 2024, 07:42:34 PMBut what stands out above is that there is a portion of the email that was treated as 7-bit and entity encoded, and not base64 encoded. I suspect both Kindred & vbgamer45 were on the right track... There is *something* in that text that triggered special processing.
Those lines are too long and must be wrapped.
Xvost -
I am still trying to reproduce the issue - with no luck. Two more questions:
1) Does it happen on other announcements/mailers, or only when you announce that particular topic?
2) Could you send me the text of the problem message? From within Quick Edit mode, so I get all the exact BBC as posted. Just send via PM so I can reproduce.
Thanks.
BTW - Very nice site. I have a number of friends that follow trains & their history. In fact, I have a close friend who is traveling to see one of the "Big Boys" up close this weekend.
https://en.wikipedia.org/wiki/Union_Pacific_Big_Boy
One or two of the Big Boys are still in operation, attracting crowds when they visit small towns.
Also just another piece of information from the discoveries made last year of users using the PSL MOD, SMF sendmail() function doesn't give a flying ****** about the things it receives, and expects the strings to be already trimmed.
So for example, in this scenario, AnnouncementSend() could be receiving a 5000 line subject, and sendmail() won't care because neither function is trimming it like Post()
// Make sure the subject isn't too long - taking into account special characters.
if ($smcFunc['strlen']($form_subject) > 100)
$form_subject = $smcFunc['substr']($form_subject, 0, 100);
Do you use CPanel from your webhost platform?
It might be related to a bug in slightly older versions of CPanel where Exim was updated but CPanel's settings for it were not updated. If you change the settings manually it may resolve your issue.
ref.https://webdesires.co.uk/blog/cpanel-message-has-lines-too-long-for-transport/
Failing that I'd start with disabling any mods that mess with emails such as your Email Subject Length mod & use some trial & error to see if one of them is the culprit.
It is possible that this is a bug, but I cannot reproduce it. My host is clearly filtering/altering the data, making it hard/impossible to reproduce.
SMF sendmail usually sends the mail in two different formats: 7-bit plain text (in theory for older clients) and utf8, which is base64 encoded & chunked up into 80 byte chunks.
My suspicion is that the 7-bit portion of the email sent is not being checked for a 1000 byte limit per line as it should. It basically just sends the text. I don't see any length check in the sendmail/mimespecialchars routines for 7-bit.
https://stackoverflow.com/questions/25710599/content-transfer-encoding-7bit-or-8-bit
Since I cannot find this 1000-byte check occuring in the code, I logged an issue:
https://github.com/SimpleMachines/SMF/issues/8288
The reason I cannot confirm it is that it appears my host strips the 7-bit entirely...
When I send something that looks like this to my SMTP server:
X-Mailer: SMF
Mime-Version: 1.0
content-type: multipart/alternative; boundary="SMF-a937f56445fd3145753c93750a6c9850"
content-transfer-encoding: 7bit
Content-Length: 35094
Восени 2020-го року, я вирішив, що технічно формат проекту не
...
--SMF-a937f56445fd3145753c93750a6c9850
content-type: text/plain; charset=UTF-8
content-transfer-encoding: base64
TGluazogaHR0cHM6Ly93d3cuc2ltcGxlbWFjaGluZXMub3JnL2NvbW11bml0eS9pbmRleC5waHA/
bXNnPTQxNzY2ODkNCg0KQW5vdGhlciBsaW5rOmhlcmUuDQoNCmh0bWwgbGluazogbGluayB0ZXh0
DQoNCtCS0L7RgdC10L3QuCAyMDIwLdCz0L4g0YDQvtC60YMsINGPINCy0LjRgNGW0YjQuNCyLCDR
My mail client receives something that looks like this:
X-Mailer: SMF
Mime-Version: 1.0
content-type: multipart/alternative; boundary="SMF-a937f56445fd3145753c93750a6c9850"
content-transfer-encoding: 7bit
--SMF-a937f56445fd3145753c93750a6c9850
content-type: text/plain; charset=UTF-8
content-transfer-encoding: base64
TGluazogaHR0cHM6Ly93d3cuc2ltcGxlbWFjaGluZXMub3JnL2NvbW11bml0eS9pbmRleC5waHA/
bXNnPTQxNzY2ODkNCg0KQW5vdGhlciBsaW5rOmhlcmUuDQoNCmh0bWwgbGluazogbGluayB0ZXh0
DQoNCtCS0L7RgdC10L3QuCAyMDIwLdCz0L4g0YDQvtC60YMsINGPINCy0LjRgNGW0YjQuNCyLCDR
This problem is much worse for folks with languages with multi-byte charsets.
E.g., this 198-character line in Ukranian:
Восени 2020-го року, я вирішив, що технічно формат проекту не відповідає вимогам часу. Тому рішуче почав перебудовувати сайт на новий движок - WordPress. Планувалось, та й так і сталося, що найбільш
Becomes this 1080 byte line in the 7bit chunk of an SMF email body, which is out of compliance with the RFC:
Восени 2020-го року, я вирішив, що технічно формат проекту не відповідає вимогам часу. Тому рішуче почав перебудовувати сайт на новий движок - WordPress. Планувалось, та й так і сталося, що найбільш
As a result, the 1000 byte limitation is much tougher on languages with multibyte characters.
The fix is a more difficult question... Introducing linebreaks into those long lines will chop up the source content in an unnatural way. It'd be ugly.
I wonder if we can just abandon the 7-bit encoding altogether, and just keep the base64 encoded utf8.
Yes, that's what I would suggest that we do
The further, the more interesting. As the previous problem was solved with the help of a crutch, here is a new one. Now the same, but with password recovery emails.
Error message:
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[email protected]
message has lines too long for transport
Reporting-MTA: dns; ova.in.ua
Action: failed
Final-Recipient: rfc822;[email protected]
Status: 5.0.0
Return-path: <[email protected]>
Received: from ova.in.ua ([95.215.157.210]:49970)
by ova.in.ua with esmtpa (Exim 4.96)
(envelope-from <[email protected]>)
id 1sQjdu-002tL8-2u
for [email protected];
Mon, 08 Jul 2024 10:22:38 +0200
Subject: =?UTF-8?B?0J3QvtCy0LjQuSDQv9Cw0YDQvtC70Ywg0LTQu9GPINCf0L7RgdGCINCS0L7RgNGB0LrQu9Cw?=
To: <[email protected]>
From: "=?UTF-8?B?0J/QvtGB0YIg0JLQvtGA0YHQutC70LA=?=" <[email protected]>
Date: Mon, 08 Jul 2024 08:10:58 -0000
Message-ID: <[email protected]>
X-Mailer: SMF
Mime-Version: 1.0
content-type: multipart/alternative; boundary="SMF-c1cadc99ce0a620dabeee9e10332e0ba"
content-transfer-encoding: 7bit
X-Exim-DSN-Information: Due to administrative limits only headers are returned
The standard text of the password recovery letter in Ukrainian:
Вітаємо ...,
Цей лист було надіслано у зв'язку з тим, що до вашого облікового запису було застосовано функцію відновлення пароля. Щоб встановити новий пароль, перейдіть за наступним посиланням:
...
IP: ...
Ім'я користувача: ...
Regards,
...
I did a little research, why in one case the letters with the Ukrainian text are sent correctly, in the other - they are not sent and we get a response from the mail server about an error.
It turned out that in all cases where the letter was not sent and caused an error message from the server, the text contained an apostrophe character (U+0027):
ʼIf you correct the text of the worksheet template so as to avoid using the apostrophe, the sheets will be added correctly, without any errors.
Those same people are fussing about those who announced the announcement of a deal. The first words are written with an apostrophe:
QuoteВосени 2020-го року, я вирішив, що технічно формат проекту не відповідає вимогам часу. Тому рішуче почав перебудовувати сайт на новий движок - WordPress. Планувалось, та й так і сталося, що найбільш цікаві матеріали будуть перенесені у вигляді окремих статей. Але час та вимоги, що з'явилися, розставили всі крапки над «ї».
That's interesting. Apostrophes are totally valid, & cause no issues that I can see in my tests.
If issues return, I suggest editing the template to keep paragraphs short - fewer than 140 Cyrillic characters between line feeds.
Another possibility is to step you thru removing the 7bit encoding altogether. It's a pretty simple edit, and would look better than a bunch of short paragraphs & sentences. (But might be a problem if you have users with very old email clients...)
My host just strips them entirely if there is valid utf8/base64 content. It might be worthwhile asking your host if that is a possibility also.
@shawnb61 looks like you are right. It's not about the apostrophe here. Revised the entire Email message templates, editing everything so that each paragraph did not exceed 140 characters. Everything seems to work.