Hacker News Reader

Comment by giovannibajo1 | Hacker News Reader

The feature is useful for desktop applications that want to help the user compose a mail to the customer service, including some report logs as attachment.

Notice that the user is still required to actually press Send in front of their default mail client with an open window showing the full email and attachments.

View on HN

I can't imagine any scenario of a widely used email app opening a hyperlink that automatically composes and attaches local files being acceptable, even if they have to click send.

What about sending crash reports or log files? Or some kind of internal workflow where you need to send something from one PC to another and this is the most convenient solution? (I could imagine some kind of tool that semi-automatically sends email but you don't wanna give it your SMTP credentials so it has to work with your MUA. Sounds weird but these kinds of awful problems with awful solutions exist probably en masse.)

(Addendum: See spacebar heating macro XKCD.)

Our program has documents attached to declarations. These typically come from some integration and is saved on a server/shared drive, in some arbitrary sub-directory to avoid too many files in one directory, and typically with some non-intuitive filename for good measure.

Our users want to be able to be able to open a declaration and email the documents, either internally or to their customers, along with some message.

We don't really want to implement a full email client in our program nor having to deal with their SMTP server setup, including proxies, firewall and so on. So we basically do exactly this, open a new mail in their client with some template text and with one or more attachments.

We use MAPI though and not "mailto:", but use-case is there.

If it does this without prompting the user for permission, it should stop doing that.

Our program doesn't prompt the user for permission explicitly, but then the user has to initiate this process by clicking the "email documents" button so...

> How can someone build such a feature and not consider the most basic security concerns?

How can someone press the "Send" button on a email without checking Subject:, TO:, CC:, and attachment list for plausibility?

(A mail-client could contain basic "warn"-lists of credential-holding places, containing a few dozen file names covering 99% of current platforms/programs)

And some "advanced" config options to also configure allowed URI schemes.

I think we've kind of established that, especially when it comes to security, that the onus is on the software to set secure and sensible defaults. I do not think an email client accepting untrusted input to automatically attaching any arbitrary file to the email is sensible or secure.

> A mail-client could contain

but it doesn't.

Reply on news.ycombinator.com