Attribute [cc] of the tag [mail] is invalid

We started getting this error after the upgrade to 5.3.8.201:

Attribute [cc] of the tag [mail] is invalid

We have code that puts a list of emails in the cc attribute, like so:

<cfmail … cc="foo@bar.com,bar@foo.com," …>

We were able to resolve our error by removing the trailing comma, but I wanted to share the report of the problem here in case it is worth filing a bug for or fixing.

I saw also this ticket that might be related:
LDEV-2234

OS: Windows
Lucee Version: 5.3.8.201

1 Like

did that previously work? or just fail in the spool process. if MTAs accept that, then we should fix it

there were a number of changes to the mail validation, not just the immediate validation.

@Zackster I don’t think the MTAs accept a trailing comma.

Maybe prior versions of Lucee were (perhaps inadvertently) fixing the trailing comma. It works fine in 5.3.7.48.

works fine, or just doesn’t blow up?

prior to 5.3.8 it would would just die in the async spooler, hence the change

This is coming from 5.3.8.53-SNAPSHOT onwards(https://luceeserver.atlassian.net/browse/LDEV-2234). This is the commit that causes this issue fixes LDEV-2234 · lucee/Lucee@2f3f57f · GitHub. Trailing comma that works fine before 5.3.8.53-SNAPSHOT from the above commit trailing comma causes this issue.

bug filed https://luceeserver.atlassian.net/browse/LDEV-3687

we had similar messages ‘Attribute [from] of the tag [mail] is invalid’ in breaks where we had commas in the display name of from address, causing a full break. previously these didn’t break completely. not looking for any change, just want to share observation.

appears to be working correctly for us in all versions
emails like:
"blah, inc" <noreply@blah.com>

some occurrances someone had changed to appending together vars together, which dropped the quotes wrapping the display name portion, resulting in emails like:
"blah, inc <noreply@blah.com>"

we fixed our code, and weren’t going to complain about it, because we considered the missing quotes wrong, but it definitely was a behavior change.

up through 5.3.7.47
would send an email as if the from was:
inc <noreply@blah.com>

after 5.3.7.47
full break, no email sent

1 Like

Can you add that as a comment to the issue? That’s a regression we’ll probably definitely address too, even tho I like stricter behaviour