Develop Reference

Show a mail in edit format with attached file or HTML table content in the body

I need to open an email popup in edit mode. The email needs to have either a HTML table in the body or an excel sheet with the data attached to it.
The email generation in edit mode is currently being achieved using "mailTo" from JavaScript. But it seems mailTo doesn't support HTML content or attaching files.
The goal is to minimise the number of steps needed to view the data.
Things that don't work:
I can't use an EML file because it's opening in a way that doesn't allow me to edit the email and I've to move it to drafts in order to edit it - which fails the whole purpose. If there's a way to open it in the edit mode, please do suggest.
AppleScript also seems to have stopped supporting HTML content.
Cannot generate a new link to download the excel file because that's too many steps to view the data.
javax.mail package - this seems to work only to directly send the email which doesn't serve my purpose. I also used this for my EML approach (1)
Technologies available: Java 8, AngularJS, JavaScript
Any help or suggestions are appreciated. Thanks in advance for your time.

Just opened an HTM file with the following code, is it dangerous?

I received an email from an unknown person and opened an htm file in the attachment file. The following code executed :
<frameset onpageshow="document.location.replace(window.atob('aHR0cHM6Ly9tdXNrLmJ0Y2RvbmF0dmVyLnNpdGUvPzI0NDc1NTgg'));">
Did I just execute something that could harm my computer ?
Thank you,
Thomas

It may be dangerous to open email attachments received from untrusted sources, in general.
In your code, in particular, the following is happening:
window.atob API is called to decode aHR0cHM6Ly9tdXNrLmJ0Y2RvbmF0dmVyLnNpdGUvPzI0NDc1NTgg base64 encoded string. See https://developer.mozilla.org/en-US/docs/Web/API/atob for the API reference.
Using the free online base64 decoder (https://www.base64decode.org/ for example) you may translate aHR0cHM6Ly9tdXNrLmJ0Y2RvbmF0dmVyLnNpdGUvPzI0NDc1NTgg and get https://musk.btcdonatver.site/?2447558 .
On opening this page your browser may navigate to that URL, see document.location.replace API call
Now, it depends on what https://musk.btcdonatver.site/?2447558 is doing.
Please, do not open attachments from unknown people and untrusted sources. They may contain malicious contents, phishing and content that may do damage otherwise.

This sets the window location to
https://musk.btcdonatver.site/?2447558.
Looks like a scam but not sure. Possible wont do any harm unless you do something by visiting to that link.

How use relative paths on MJML with mjml-react for email templates

Describe the bug
The use of relative paths render broken links on the email recipient
The use of links from images on the web generate broken links on the email, except for the case that these links have a termination which explicitly names an image, with its type (jpg, etc), e.g src="http:://somelink....jpg"
To Reproduce
Relative path does not work:
<MjmlImage
width="400px"
src="./public/Book/Book.png"
></MjmlImage>
Only this kind of link that works:
<MjmlImage
width="400px"
src="https://image.shutterstock.com/image-photo/bright-spring-view-cameo-island-260nw-1048185397.jpg"
></MjmlImage>
Expected behavior
The image should show on the email of the recipient.
MJML environment (please complete the following information):
OS: Windows
MJML Version 4.7.1
MJML tool used: mjml-react 1.0.61
Email sending environment(for rendering issues):
Platform used to send the email: Gmail
Affected email clients (for rendering issues):
Email Client: Gmail
OS: Windows
Browser: Google Chrome
Screenshots
Additional context
I tried using this package and followed the steps for webpack on my next.config.js file (I am using NextJs) but it did not work also.

In the general case:
Relative addresses work on your system as you're developing your email.
Sadly, there's no way to send external files with your email. Hence, files you can find with relative addresses on your system are unlikely to be present on your recipient's system.
You'll want to put your files at Internet-reachable URLs and refer to them that way in your emails.
As you observed, that works well when you reference the entire path and filename, including the extension.
In your case:
The package you're using strives to be a way to send images with your email. Nifty. If it works, it hides lots of complexity.
I notice about that package that it hasn't been updated in two years or more. If it worked then, it'd be no surprise that it no longer works. Good luck!
Extras: Be careful with sending your email. Every email client I've heard about changes your HTML if you use cut-and-paste to put the HTML in their editor for sending. If they change your HTML, you're not sending what you thought you were sending. Bummer. The fix is to use an email service provider. Some are free for a limited number of emails sent. Pick one that doesn't change your HTML; some do!
You can test your HTML by pasting it into the free service https://putsmail.com (don't click the option to inline your CSS). They'll send the email to the email account of your choice and you can check it in the email client of your choice.
By the way, a great source of MJML support is https://slack.mjml.io/.

How to attach blob file into HTML href="mailto:"

I have a file available through an URL (need authorization). I created a mailto: link and would like to attach this file in the mail. How can I do that ?
Something like "mailto:toto#gmail.fr&attachment=site.com/file.pdf"

mailto: doesn't support attachments, but there are various ways you could achieve a similar effect:
Link to the file in a message body
You mentioned that the link needs authorisation, you could generate temporary urls that last 30 minutes (or more/less) which allow for downloads (users can then attach the file themselves)
Send the email yourself
Your service could send an email to your user (or on behalf of your user) with the attachment using something like Amazon SES, or Mailchimp, etc...
Render your PDF into HTML
It seems you are planning on attaching PDF files. Depending on the complexity of the PDF files, you could attempt to convert the PDF into email-friendly HTML using one of many tools, such as pdf2htmlEX or Pandoc.

If you're hoping for an universal solution, you can't. The mailto protocol described in the RFC 2368 tells us :
The creator of a mailto URL cannot expect the resolver of a URL to
understand more than the "subject" and "body" headers.
Even though other headers might be used and understood by some mail clients, this isn't an universally compatible solution. Unless you tell your clients to open these links specifically with a specific mail client that you know supports more headers (like a hypothetical attachment header), you should consider this to not be doable.

make ASP.Net file upload secure

I'm creating an ASP.Net form with a fileupload control which will then email the details of the form and the file to another admin. I want to ensure this secure (for the server and the recipient). The attachment should be a CV so I will restrict it to typical text documents.
From what I can tell the best bet is to check that the file extension or MIME Type is of that kind and check it against the "magic numbers" to verify that the extension hasn't been changed. I'm not too concerned about how to go about doing that but want to know if that really is enough.
I'd also be happy to use a third party product that takes care of this and I've looked at a couple:
blueimp jQuery file upload
http://blueimp.github.io/jQuery-File-Upload/
and cutesoft ajaxuploader
http://ajaxuploader.com/Demo/
But blueimp one still seems to require custom server validation (i guess just being jQuery it just handles client-side validation) and the .net one checks the MIME-type matches the extension but I thought the MIME type followed the extension anyway.
So,
Do I need to worry about server security when the file is added as an attachment but not saved?
Is there a plugin or control that takes care of this well?
If I need to implement something for server validation myself is matching the MIME-type to the "magic numbers" good enough?
I'm sure nothing is 100% bulletproof but file upload is pretty common stuff and I assume most implementations are "safe enough" - but how!?
If it's relevant, here is my basic code so far
<p>Please attach your CV here</p>
<asp:FileUpload ID="fileUploader" runat="server" />
and on submit
MailMessage message = new MailMessage();
if (fileUploader.HasFile)
{
try
{
if (fileUploader.PostedFile.ContentType == "text")
{
// check magic numbers indicate same content type... if(){}
if (fileUploader.PostedFile.ContentLength < 102400)
{
string fileName = System.IO.Path.GetFileName(fileUploader.PostedFile.FileName);
message.Attachments.Add(new Attachment(fileUploader.PostedFile.InputStream, fileName));
}
else
{
// show a message saying the file is too large
}
}
else
{
// show a message saying the file is not a text based document
}
}
catch (Exception ex)
{
// display ex.Message;
}
}

A server can never be 100% secure, but we should do our best to minimize the risk on an incident. I should say at this point that I am not an expert, I am just a computer science student. So, here is an approach that I would follow in such a case. Please, comment any additional tip you can give.
Generally speaking, to have a secure form, all client inputs must be checked and validated. Any information that does not origin from our system is not trusted.
Inputs from the client in our case:
file's name
name
extension
file's content
Extension
We don't really care about the minetype, this is info for a web server. We care about the file extension, because this is the indicator for the OS on how to run/read/open a file. We have to support only specific file extensions (what ever your admin's pc can handle) there is no point supporting unknown file types.
Name (without the extension)
The name of the file is not always a valuable info. When I deal with file uploading I usually rename it (set it) to an id (a username, a time-stamp, hashes etc). If the name is important, always check/trim it, if you only expect letters or numbers delete all other chars (I avoid to leave "/", "\", "." because they can be used to inject paths).
So now we suppose that the generated file name is safe.
Content
When you support no structured files, you just can not validate the file's content. Thus, let an expert program do this for you... scan them with an antivirus. Call the antivirus from the console (carefully, use mechanics that avoid injections). Many antivirus can scan zips contents too (a malicious file, in a folder on your server is not a good idea). Always keep the scan program updated.
On the comments I suggested zipping the file, in order to avoid any automatic execution on the admin's machine and on the sever. The admin's machine's antivirus can then handle it before unzip.
Some more tips, don't give more information's to the client than he needs... don't let the client know where the files are saved, don't let the web-server access them for distribution if there no need to. Keep a log with weird actions (slashes in filenames, too big files, too long names, warning extensions like "sh" "exe" "bat") and report the admins with an email if anything weird happen (it is good to know if your protections work).
All these creates server work load (more system holes), so you may should count the number of files that are scanned/checked at the moment before accepting a new file upload request (that is where I would launch a DDoS attack).
With a quick google search Avast! For Linux - Command Line Guide, I do not promote Avast, I am just showing it as an existing example.
Lastly but not least, you are not paranoid, I manage a custom translation system that I coded... spams and hack attacks have occurred more than once.
Some more thoughts, JavaScript running on a web-page is only secure for the client's computer (thanks to the browser's security). We can use it to prevent invalid posts to the server but this does not ensures that such requests will not be done as JavaScript can be bypassed/edited.
So, all JavaScript solutions are only for a first validation (usually just to help the user correct mistakes) and to correctly set the form data.