ElkArte Community

It seems that there may be an issue with the emails sent to new members on my sites.
I have it set to email activation, and here's how the email shows up:


Not sure why the activation links are getting spaced out by line break. The language file shows fine:

/**
	@additional_params: resend_activate_message
		REALNAME: The display name for the member receiving the email.
		USERNAME:  The user name for the member receiving the email.
		ACTIVATIONLINK:  The url link to activate the member's account.
		ACTIVATIONCODE:  The code needed to activate the member's account.
		ACTIVATIONLINKWITHOUTCODE: The url to the page where the activation code can be entered.
		FORGOTPASSWORDLINK: The url to the "forgot password" page.
	@description:
*/
$txt['resend_activate_message_subject'] = 'Welcome to {FORUMNAME}';
$txt['resend_activate_message_body'] = 'Thank you for registering at {FORUMNAME}. Your username is {USERNAME}. If you forget your password, you can reset it by visiting {FORGOTPASSWORDLINK}

Before you can login, you must first activate your account by selecting the following link:

{ACTIVATIONLINK}

Should you have any problems with the activation, please visit {ACTIVATIONLINKWITHOUTCODE} and enter the code "{ACTIVATIONCODE}".

{REGARDS}';

That is usually the email client parsing BK, not the sender...

For example, in my pegasus client I get this link..


but in my Roundcube webmail interface I get...


FWIW, in your email link..

[Link]( https://www.allpointswh.com/index
.php?action=register;sa=activate;u=99;code=6ab5EJupiteruGjy )


All one has to do is copy/paste the bolded text into the browser address bar, or, if the client allows, select the bolded text, and right-click for the menu, click "open as a hyperlink" or something similar..

I use Gmail, and it seems that for some reason it shows up narrow.
I believe that is why they are getting cut off like that.
I was wondering if there might be a fix, like setting a minimum width for the emails.

I can't help there, I don't use gmail. But, if I had to make a suggestion, that would be my fix   😁😁😁  

You cannot do anything about this, really. HTML is not part of SMPT and the fact that people use HTML in E-Mails have been frowned upon by old timers ever since the first E-Mail with HTML was sent :)

E-Mail clients like Alpine (https://alpineapp.email/) and mutt (http://www.mutt.org/) etc. doesn't do very good rendering HTML "infested" E-Mails, for they do not have web engines nor JavaScript in them.

It's upto the E-Mail client program how the content is rendered.

Bottom usability tip for writing HTML E-Mails like the above is that you always should include the plain text hyperlinks along with the HTML ones. This way you ensure that people using CLI based E-Mail clients get them.

Took out what felt was needed to be removed for security purposes.
Looks like it was sent via plain text, not HTML: Content-Type: text/plain; charset=UTF-8

Delivered-To: 
Received: by 2002:a05:6358:7404:b0:e2:d70d:38a1 with SMTP id s4csp7827216rwg;
        Thu, 29 Dec 2022 14:30:15 -0800 (PST)
X-Google-Smtp-Source: AMrXdXvHOB9EUe9fU9Si/hcMjVaWyhEMLuOM+UfSaX6LjunpuBVzSebKpTl9du9mJmh5V5iLIQrA
X-Received: by 2002:a05:6402:f04:b0:46d:ca42:2e59 with SMTP id i4-20020a0564020f0400b0046dca422e59mr28480211eda.11.1672353015464;
        Thu, 29 Dec 2022 14:30:15 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1672353015; cv=none;
        d=google.com; s=arc-20160816;
        b=SSTrAnOMzXpOwtY9EcTMMJO0CSfNW4VN7sLLfdw8/clv3Bm9LD6GDra/CYs0aZVIRL
         yJxFYQIFdCo9NUjHFNQI9s7lgF8mNoKQe46zwtigcrcKEALk9DIMpI1fXaasc5u3ZXoY
         UMFRXT8GitCb6DNtSnw5oQRhj6A3p95f3KMyuztEkpSuYIugghoi2soTWtiSYPb0CGgd
         xYRCLKlXXpyiGx2mYhPK5LepWyflrhgZqVZcktfbbTQ60hsZpksTMQGr8Ldo/nOjxkrc
         DWRaxFJXNHBXtiX3vOrttLtcVmasGk2HYt5zCbzbXxUkom97AR2DcuINfUxxbCS/CJXx
         vTTA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=message-id:content-transfer-encoding:mime-version:date:from:subject
         :to;
        bh=7rmkbSHvsakf7w2sEcBq49HgLXeDAwQXhq2ams7r20c=;
        b=0xe875o5wiMpN5wY0DzZLBvwGUsQ3mp/rojIFMj5oVheJsYvbTwZmosRiIja4ychbV
         GY4+xGqyeTByR3Wxd0v+SuOM6NgmXP6VKCs+Tq/d7YeW4WghB2zZiZe2OKf07DfhEvEN
         c1qBeeDdEeRtnqG6roM1ej4cn0CckW4rt3YxYBU6FHoFOD/k276EW/y2t5LT59Rq4Elx
         k748qVsKWi7DKJRYRbQiOabiRnkJCWLfHDxcoKUmmwnKDdv3aICBNMVDMlNO0KOXwjii
         Egf+aM9cjs8bkdeipObC2KT/IxK6HkElXQSUbVsefztEXbvf0rxq10T64nLtZYTwlJB5
         A1rA==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=neutral (google.com: 82.163.176.31 is neither permitted nor denied by domain of allpointswh.com) smtp.mailfrom=allpointswh.com
Return-Path: <allpointswh.com>
Received: from  ()
        by mx.google.com with ESMTPS id j8-20020aa7c0c8000000b00467960d3013si14598226edp.43.2022.12.29.14.30.15
        for <>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 29 Dec 2022 14:30:15 -0800 (PST)
Received-SPF: neutral (google.com: 82.163.176.31 is neither permitted nor denied by domain of allpointswh.com) client-ip=82.163.176.31;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 82.163.176.31 is neither permitted nor denied by domain of allpointswh.com) smtp.mailfrom=allpointswh.com
Received: from scottjbr by  with local (Exim 4.94.2) (envelope-from <allpointswh.com>) id 1pB1Pi-000Eep-E8 for scottjb9276@gmail.com; Thu, 29 Dec 2022 17:30:14 -0500
To: 
Subject: Welcome to All Points Web Hosting
X-PHP-Script: www.allpointswh.com/index.php for 
X-PHP-Filename: allpointswh.com/index.php REMOTE_ADDR: 67.6.59.123
From: All Points Web Hosting <allpointswh.com>
Date: Thu, 29 Dec 2022 22:30:14 -0000
X-Mailer: ELK
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="ELK-28c69c00e41305d4993daa86e71fde43"
Content-Transfer-Encoding: 7bit
Message-ID: <fa356f999d47f071c4b78b35f40a15ed-@allpointswh.com>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - 
X-AntiAbuse: Original Domain - gmail.com
X-AntiAbuse: Originator/Caller UID/GID - [1459 501] / [47 12]
X-AntiAbuse: Sender Address Domain - allpointswh.com
X-Get-Message-Sender-Via: : authenticated_id: from_h
X-Authenticated-Sender: : allpointswh.com
X-Source: 
X-Source-Args: 
X-Source-Dir: allpointswh.com

--ELK-28c69c00e41305d4993daa86e71fde43
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

VGhhbmsgeW91IGZvciByZWdpc3RlcmluZyBhdCBBbGwgUG9pbnRzIFdlYiBIb3N0aW5nLiBZb3Vy
IHVzZXJuYW1lIGlzClNjb3R0SkI5Mjc2LiBJZiB5b3UgZm9yZ2V0IHlvdXIgcGFzc3dvcmQsIHlv
dSBjYW4gcmVzZXQgaXQgYnkgdmlzaXRpbmcgCltMaW5rXSggaHR0cHM6Ly93d3cuYWxscG9pbnRz
d2guY29tL2luZGV4LnBocD9hY3Rpb249cmVtaW5kZXIgKSAgCgoKCkJlZm9yZSB5b3UgY2FuIGxv
Z2luLCB5b3UgZmlyc3QgbmVlZCB0byBhY3RpdmF0ZSB5b3VyIGFjY291bnQuIFRvIGRvIHNvLApw
bGVhc2UgZm9sbG93IHRoaXMgbGluazogIAoKCgoKW0xpbmtdKCBodHRwczovL3d3dy5hbGxwb2lu
dHN3aC5jb20vaW5kZXgKLnBocD9hY3Rpb249cmVnaXN0ZXI7c2E9YWN0aXZhdGU7dT00O2NvZGU9
NkhpNUVKcEdUQXVHankgKSAgCgoKClNob3VsZCB5b3UgaGF2ZSBhbnkgcHJvYmxlbXMgd2l0aCBh
Y3RpdmF0aW9uLCBwbGVhc2UgdmlzaXQgCltMaW5rXSggaHR0cHM6Ly93d3cuYWxscG9pbnRzd2gu
Y29tL2luZGV4Ci5waHA/YWN0aW9uPXJlZ2lzdGVyO3NhPWFjdGl2YXRlO3U9NCApIHVzZSB0aGUg
Y29kZSAiNkhpNUVKcEdUQXVHankiLiAgCgoKClJlZ2FyZHMsICAKClRoZSBBbGwgUG9pbnRzIFdl
YiBIb3N0aW5nIFRlYW0uCg==
--ELK-28c69c00e41305d4993daa86e71fde43--

It's "possible" that if the html address is encased in angle brackets when sent,

 [Link]( <https://www.allpointswh.com/index.php?action=register;sa=activate;u=99;code=6ab5EJupiteruGjy> )

..the client will not "break the link" at a punctuation mark within the address. Otherwise, for sure, the parser has no clear idea when the end of the url is.

However, that may not stop the wrapping, but it may make clicking on any part of the URL function as a complete url.

Something for @Spuds to take a look at, perhaps. That said, it's virtually impossible to code url html so it renders the same in every different client, since every client does things differently..

Edit: Spuds may already be doing that. The full url link is active in html no matter where it breaks to a new line or where you click the link

If it’s sent via html and plain text then the html should be abided by. i.e if it’s in a tags then that should be followed. Well most clients do…

I’ll have a play if @spuds isn’t already

I presume that EA's email formatting template is the same for authentication as for emailed posts...

This is what I get in plain text view.

---

ElkArte Community Links:

 To visit ElkArte Community on the web, go to: 
[X](https://www.elkarte.net/community "Link")

 You can see this message by using this link: 
[X](https://www.elkarte.net/community/index.php?topic=6190.msg44383#msg44383 "Link")

 You can go to your first unread message by using this link: 
[X](https://www.elkarte.net/community/index.php?topic=6190.new;topicseen#new "Link")

 Unsubscribe to this Board by using this link: 
[X](https://www.elkarte.net/community/index.php?action=notify ;sa=unsubscribe;token=1192_eJ1AYTsHx1.ZWKwQSnjPX9bu_board_17_1672446109 "Link")

Regards, The ElkArte Community

---

This is what I get in html/rich-text view

ElkArte Community Links:

 <*> To visit ElkArte Community on the web, go to:
https://www.elkarte.net/community

 <*> You can see this message by using this link:
https://www.elkarte.net/community/index.php?topic=6190.msg44383#msg44383

 <*> You can go to your first unread message by using this link:
https://www.elkarte.net/community/index.php?topic=6190new;topicseen#new

 <*> Unsubscribe to this Board by using this link:
https://www.elkarte.net/community/index.php?
action=notify;sa=unsubscribe;token=1192_eJ1AYTsHx1.ZWKwQnjPX9bu_board_17_1672446109 <--EA doesn't recognize this as part of the link when pasted into this post  :tongue:

 Regards, The ElkArte Community

---

In each version, the green underlined text contains the URL that is shown in green underlined text  

( In other words, the rendered text links are ONLY the URL shown as green underlined text. The non-underlined text (after the semi-colon) is not active, nor included in the rendered url. There's nothing EA can do about that, methinks.
To use the chopped ones I have to make sure I manually select the entire url and enter that in the browser address bar.
 In HTML, the full link is displayed (in Pegasus), even though wrapped at the "?" (and there's nothing EA can do about that either, I believe)., yet the full link is active and rendered completely. Click on any part and I get the full url.)
This is in Pegasus, running IER 2.6.6.0 (a slightly newer version is available but I haven't installed it) which is Pegasus html handler. It's a little different in Roundcube
Your mileage may vary depending on how your client handles text-based url links and/or pre-processes html url links. 
Also, this is what I get from the EA version running on the EA site  (Spuds and I recently ran through a bunch of different email formatting scenarios in the current version running on EA ). Spuds will have to confirm whether that is the same code in the EA version you are running @Burke_Knight.  

(And last, yes, the displayed unsub link has been modified and should be rejected by EA code if someone clicks it..) 🥴

And, the same email only two different email clients..

Same code, different clients, different results...

(Link-10197)

(Link-10201)

From what I can tell the links are still parsed correctly in the two clients? Which is the main issue to resolve.

Correct - it's a client issue, not an ElkArte issue. If you notice, the links in HTML/Rich-Text work correctly in each client (even with the line-wrapping).  Of my examples, it's only Pegasus in plain text mode that goofs it up.  Someday I presume Pegasus will fix that (too).
See the roundcube html links - because of its particular interface it wraps the last long link twice. It still works. I imagine a smartphone would wrap that link onto 4 or 5 separate lines (or do something like https://www.elkarte.net/community/index.php?action=.....)

So, it doesn't matter how much or what formula of Techron that Chevron puts in their gas, it's not gonna make Leroy's old motor with the worn rings and blown head-gasket pass the annual emissions-check.  :cheesy:  (If they tried to it would probably start messing up other motors instead).

The email issue(s) are a bit of a saga.  

Going way back to the original fork point, the existing email function sendmail was super janky (of course IMO) It was littered with ancient conditionals and other cruft.  So knowing that, we did what you always do, build on top of it ... nothing wrong with building on a weak foundation, that never comes back to :punch: :face_with_spiral_eyes: back.   As issues showed up, mainly with our PBE (Post by Email / Listserver) functionality, various areas were updated, which of course exposed other issues.

Note that in 2.0 I could not take it any longer and redid the entire email function, such that whoever picks this up in the future can call it janky!  The new functions will send real HTML, not what occurs in 1.1 which is plain or base64 text but sent as HTML.   By real HTML I mean crusty old HTML wrapped in tables and inline style ... this due to the fact that there are some real old dinosaur email clients out there, and those are what render the HTML so you have to use some ugly markup.

Anyway, in 1.1 various attempts were make to live with it, and there were various "fixes" applied to the email formatters and converters, which often caused other interesting problems.  1.1.9 continues on that fine tradition, and again made updates, mostly back ported from 2.0.  One area that can cause the break is when we convert the email to markdown syntax (as its more expressive then plain text, and we don't due HTML).  There was a wrapping issue in that as I recall.

I'll check if the 1.1.9 file will work in 1.1.8, just as a test, but that may not fix it at all.  As noted, often the email client will butcher those links, and we have tried the <> trick and several others.  Often the client just grabs the first section (plain text) uses that and then wraps it at 78-80 characters, and a period is a great wrap point as what is a link in plain text?  They should prefer the most 'correct' version of the message in the email plain -> base64 encode -> html but that does not always happen (and some shut of HTML anyway)

I'll give the new function a spin on 1.1.8 just for the experiment and report back.

Going back to the original post by BK, I think the complaint was the wrap of the link - not that the link didn't work. If that is the case, there's nothing EA can do about that, as that is purely the function of the client interface. With long urls, the client has to do something for presentation purposes. If it's a smartphone display, I've often seen the url truncated and "....." concatenated to the displayed url (and I'm reluctant to click a link I can't read all of, so that's not my ideal solution), instead of wrapping.

Now, if the link is "broken' (click on it and it doesn't call the intended resource), that can be fixed server side (in most cases), but not all (as the plain text chops them up in Pegasus shows). Nothing EA can do to fix the Pegasus rendering, nor should it try - the  other clients all handle those links just fine in plain text. It's a Pegasus problem.

So maybe the first question should be back to @Burke_Knight - is this an aesthetic issue, or a function issue?  The latter is resolvable, but aesthetic is purely a client issue.

Edit: For the record, this is what I get from EA 1.1.6  (no html encoding at all..)

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


<*> To visit the forum on the web, go to:
    h...s://mydomain.com/myforum

<*> You can see this message by using this link:
    h...s://mydomain.com/myforum/index.php?topic=129.new#new

<*> You can go to your first unread message by using this link:
    h..s://mydomain.com/myforum/index.php?topic=129.new#new

<*> Unsubscribe to this by using this link:
    h..s://mydomain.com/myforum/index.php?action=notifyboard;board=40.0

And the last link is "broken" at the semi-colon (again, that's Pegasus)
And I had to modify the "https" so the forum wouldn't slap it's own link rendering over my display formatting when I pasted it.

@Steeley sending real html as happens with ElkArte 2 should resolve it in all instances. Even if it is html from the dark ages. If you disable that in the client or use one which doesn’t support it then you’re on your own.

The big ones however do favour html over plain text. Outlook, GMail, Thunderbird, Mail, etc

Agreed - and Pegasus renders html-formatted URL links just fine (it just messes up URL links sent plain text formatted at various punctuations within the link - again, a pegasus problem, not a server-side problem).

The question for BK is whether he is objecting to the presentation of the long URL in the email, or is the link actually "broken" (as Pegasus does to text-formatted urls).

I think what the current EA version (2.0?) is doing is fine as far as email html-formatting (which v.1.1.6 doesn't do). I'm not sure what EA version BK is using and whether it has been 'back-ported' or not, but if, as I'm assuming, it's just the presentation aesthetics (wrapped url) that isn't going to be "fixed" server-side, that's what the client is doing with it.  Virtually every client and forum I've seen now will wrap an html formatted long url at the "?" (or other embedded punctuation character), which makes sense from a human-readability point of view. The client has to do something with a long URL that won't fit on one line within its interface. 

Pegasus, like Roundcube and most other clients that support both formats have a toggle to switch between html and plain-text formatting.

No, the complaint was not just the wrap, but that said wrap broke the link.
When click the visible link before the break, it goes to:

https://www.allpointswh.com/index

It does not even have the .php in the link, causing a 404.
This means it's a 100% function issue.

That said, I know they can always just copy/paste the full thing, but with a line break in the middle of a link, not sure how some browsers might react. Most should do right, but of course, with so many off-the-wall browsers out there now, one never knows...  :wink:

Edit: All my forums are ElkArte 1.1.8

Alrighty-and @Spuds is now in the loop on that. 
(If he gets a back-port for 1.1.8, instead of pushing an upgrade to 1.1.9 maybe it will work for 1.1.6 too? 🙏 . But if not no biggie for me, the text rendering works fine - if you're not using Pegasus anyway.)

After extensive testing ( it worked once ) using the html2md file from 1.1.9 on 1.1.8 did not break the link (using online gmail and a separate gmail client)

In my testing the link was fine if the core feature Post by Email Management is not enabled.  However when enabled and setup, the link can break during the markdown conversion.  If you are not using the maillist / listserver functions, this will make no difference, but in this case the site has that enabled so will see a change.

Replace your Html2Md.class.php file in sources/subs with the one attached and let us know how this works for you.

That did the trick! Thanks, @Spuds!

No surprise, when added to v 1.1.6, while it changed the second section of the email from 7bit encoding to base64 and changed that sections enclosed text to "Ck9uY2UgbW9yZSBpbnRvIHRoZSBicmVlY2gKAAoKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t......."

...none of my email clients render it in html.

I was hanging onto this thread by my fingernails (technically), and just lost my grip.. I don't see the difference in the received email formatting now between an email sent by EA 2.0 and EA 1.1.6 with this file, but from 1.1.6 the email doesn't render html at all, still, where 2.0 does just fine.  Obviously I'm missing something, something is different but I don't recognize any obvious deltas that would account for it, but ... that's OK.  Just thought I'd give it a  shot and see..





 

@Steeley, why haven't you updated to 1.1.8?

@Spuds

I just confirmed if the plain-text urls (even very long ones), are delimited with angle-brackets Pegasus renders them properly.. So, when you get a chance, Spuds., if you could 'splain to me what to modify. in 1.1.6 (since that is sending only plain-text emails..) I'd be much obliged 'n stuff, ya know?  :cool:

Well, my forum supports a bunch of old 'nam vets who are long in the tooth and dwindling in numbers, and they don't deal with changes well. Not only that, but the forum owner is also an old 'nam vet who is slowly losing his marbles  :zany_face:  and is skittish of slapping an upgrade on top of a production platform that is otherwise working acceptably. I don't mind a tweak here and there to eliminate little annoyances, but I've learned over the years that "incompatibilities are just an upgrade away".  If I had a test platform to work with that's one thing.. but I don't, so if I can make 1.1.6 continue working as I've got it set up now, I can eventually fade away with a smile on my face and a song in my heart (instead of frowns and curses trying to figure out what I just broke..).    

@Steeley I have not forgotten, I'm just stuck on some other things ATM!

No hurry.. it's just a minor niggly for a few of us, and we know how to deal with it. But if I can make a quick code edit or two so the plain-text urls are also delimited and that makes it go away, cool.

Like a pinch of powdered sugar on the cherry on an ice cream sundae.. just a nice touch to let my brothers know they're loved, ya know?

I would hazard a guess at it being this commit. https://github.com/elkarte/Elkarte/commit/70ecca4156f4e6c022f52ea49781694d1b0837d5

As that’s around the delimiters and is generally what stops html vs txt.

Very well could be, but if that is directed to me, @tino and since I don't speak php worth a darn, where and how I would edit it to insert such "<" and ">" brackets to delimit plain text urls requires "a better man than I, Gunga Din.."