Hello Brother Rabbit!
** On Monday 24.05.21 - 12:04, Brother Rabbit wrote to August Abolins:
First, it inserted a character that _isn't_ there;
secondly, it inserted a character that _shouldn't_ _be_
in the Fido messages. I mean the character 0x0A (you see
%0A).
The x0A is legit. It's the same as a hard CR when this
system prepares a message for which I've configured a
maximum of 63 chars per line.
By the way, this is a violation of the standard. The 0x0A
symbol *MUST* not be in the message at all. The 0x0D
symbol should not appear where the author of the message
did not put it with his own hands.
Hmmm.. in retrospect.. something indeed may be amiss. The 0x0A
only revealed itself at the part were the line-break occurred
for that link AFTER it showed up on your system. I don't think
it was in the outbound packet leaving my system. If my system
is the problem, then we should be seeing x0A at every
linebreak, even in this message.
What I think your bot/tosser logic algorithm could do is
look for illegal chars in the string of the (http....)
part, and simply take them out.
Although, the standard says that when processing messages,
the 0x0A character must be ignored.
Doesn't that just apply to the header/control parts, and not
the body/message?
Anyway.. if an illegal char appeared in an
https:// line posted
in a message (high ansi?) I don't see anything wrong "cleaning"
it up.
https://f�i�d�o�n�e�t.org
IOW, if it detects a [ and ] and ( and ) as consecutive
pairs, then assume it is markup for a link, and then only
allow valid chars inbetween the round braces.
Yes. I can put such a spike, but it will mean that
formally I will have to change the message, which in
itself is not entirely good.
But you're already changing the message when the marked up
version goes through the Fido2telebot tosser on it's way to
Telegram. No?
--
../|ug
--- OpenXP 5.0.50
* Origin: tg_bbs->
https://t.me/joinchat/TWCQfOZqwwOmweR1 (2:221/1.58)
