## Summary
Nodemailer's address parser can produce an unexpected recipient address when an RFC 5322 comment follows the domain of an address whose local-part is a quoted string.
For example:
```text
"user"@example.com(x)evil.com
```
is parsed as:
```text
{
address: "
[email protected] evil.com",
name: ""
}
```
The resulting address therefore contains additional attacker-controlled domain text separated by a literal space.
The parsed `.address` value is subsequently propagated into the SMTP envelope:
```text
src/addressparser/index.ts
↓
recipient.address
↓
src/mime-node/index.ts
↓
envelope.to
```
The envelope construction uses the parsed address without another strict address validation step.
This appears to be a variant of the RFC 5322 comment parsing issue addressed by GHSA-cc9r-2j5m-2m83, but it follows a different parser path when the local-part is quoted.
## Reproduction
Input:
```text
"user"@example.com(x)evil.com
```
Observed parser output:
```text
address: "
[email protected] evil.com"
name: ""
```
A second example:
```text
"a"@b.com(c)d.com(e)f.com
```
produces:
```text
address: "
[email protected] d.com f.com"
name: ""
```
For comparison, the corresponding unquoted form:
```text
[email protected](x)evil.com
```
takes a different code path and is handled by the existing protection differently.
## Technical Details
The issue is caused by different parsing behavior for quoted and unquoted local-parts.
The quoted-local-part variant allows the comment-separated trailing domain atoms to remain in the resulting `.address` value.
That value is then used when constructing the message envelope:
```text
envelope.to = recipients.map(to => to.address as string)
```
No additional strict recipient validation is performed at this boundary.
## Security Impact
The confirmed impact is that attacker-controlled comment content can result in a malformed/ambiguous recipient address being accepted by the parser and propagated into `envelope.to`.
The reporter did **not confirm successful delivery to an unintended recipient through a real SMTP server using this exact quoted-local-part variant**.
The remaining question is how real SMTP servers and other Nodemailer transports handle an envelope recipient containing a value such as:
```text
[email protected] evil.com
```
An end-to-end SMTP test is required to determine whether this parser behavior results in an exploitable delivery or recipient-validation bypass.
## Relationship to GHSA-cc9r-2j5m-2m83
This report is intended as a potential variant/follow-up to GHSA-cc9r-2j5m-2m83.
The existing advisory addresses RFC 5322 comment handling in email domains. This report identifies a separate parser path involving quoted local-parts that can preserve additional domain-like content in the normalized address.
Please evaluate whether this behavior is already covered by the existing fix or represents a remaining parser variant.
## Suggested Fix
The parser should consistently reject or correctly terminate addresses containing trailing domain atoms after RFC 5322 comments, regardless of whether the local-part is quoted.
In particular:
```text
"user"@example.com(x)evil.com
```
should not result in:
```text
[email protected] evil.com
```
The envelope-generation layer should also avoid assuming that a parser-produced address is safe for SMTP delivery without appropriate validation.
## Verification Status
Confirmed:
* Parser accepts the quoted-local-part variant.
* Parser produces an address containing additional attacker-controlled text.
* The resulting address is propagated into `envelope.to`.
Not confirmed by reporter:
* Successful delivery through a real SMTP server.
* Delivery to an unintended recipient.
* Exploitability against a specific downstream SMTP implementation.
