I work for the Common App and some of our functionality for users is tied to activation/opt out links via emails. I’m using Mailsac + your API primarily due to how robust the returns are.
When testing out using the links from the email via the API, I’m finding that links that occur at the end of a sentence (ex.: Please visit our website to activate your account.) will get the trailing period added to the returned link. It’s not a part of the anchor tag or href, but is being suffixed on automatically.
Any ideas why this is happening? I’m currently just running those offending links through a substring function to remove the last character but I’d love to know if this is fixable from y’alls side instead!
Thanks!
Disclaimer that I’m a front-end dev of the HTML/CSS variety - this is actually my first real work integrating an API into a testing library (Cypress) so a lot of this is super new to me.
Thanks for the detailed description. We are investigating and trying to reproduce. We will reply soon.
Are you sending both an HTML and Plain Text body in your email? If not, it may explain the issue. To fix it immediately, just sent the link as part of a plain text email body. You can still also send the HTML body.
@geebru Could you post a link to the email message or mailsac inbox you are sending the message to? I’d like the try to reproduce the issue.
If you don’t want to post the email or inbox publicly, you can message me directly or send an email to [email protected]
@ruffrey We send both versions if I recall - the emails are from a separate code base that I don’t have ease of access to. That said however I’m more familiar with the HTML version (which I updated a year ago?) than the plain text so I’m not entirely sure if they match 1:1 or if there’s issues in the PT version.
@mjmayer Yep I can definitely do that. I have some things to take care of this morning but I can send out one of these invite emails and send you the inbox in a direct message.
Here’s some background.
We default to using the plaintext for getting the list of links. Plaintext has the more important links. An HTML email may have, worse case, over 100 links to images, borders, tracking pixels, etc. Thus for practical reasons, Mailsac pulls the plaintext links only, at this time.
If your team is sending a plaintext body already, they might be adding the period on the end of the link. Since a period is a valid part of the link, our parser wouldn’t be able to tell the difference between the link and the end of the sentence.
If your team is not sending a plaintext body, then your mail sender, or mail library, might be parsing a plaintext body from the email, and mashing the period onto the end.
Finally, if Mailsac receives an email with no plaintext body, only HTML body, it will attempt to parse the HTML into plaintext contents. This drops superfluous things like display images and should leave only anchor tag links. But if an anchor tag is mashed against the end of a sentence, our parser library might mash the period onto the end of the link. It probably shouldn’t, but we’ll have to dig into that code to fix it. In the meantime, this is why I recommended sending a plaintext email body.
1 Like
Ah got it - let me send that info along to the team and see if I can’t track down if that’s the issue here. Thanks for the extra explanation!
1 Like
Just closing the loop on this - confirmed that the way our plaintext versions are created, those particularly links include a period, despite not being parts of sentences.
Scheduled some work with the team to update so that this doesn’t happen. Thanks for the quick responses and assistance, all 
Glad to hear you got it worked out.
Thanks for taking a chance and participating in our forums, I’m sure you noticed we are just getting started with them. If there is anything else I can do to be of assistance, let me know.
1 Like