Vm To Email Failures -- Comma's in "From" Header

[twitchy087]

Hey Guys,

I have a situation where GMail relays/servers have begun rejecting specific emails. Specifically, they are rejecting anything that has a comma within the from head. This comma is popped in whenever the inbound caller ID of the call has a comma added. The IPO simply passes the inbound caller ID into the From header and is seen within the email. The issue is that Gmail now see's that comma as an indication of there being 2 senders then rejects the email.

I am being told that Google will not change their behavior.

I am of the impression that we have no way to tell the IPO to stop using the inbound caller ID as the from header.

An example of what I am referring to is like this:

From: BARBER@xxxxx.com<mailto:BARBER@xxxxx.com>, DANIELLE <voicemail@yyyyy.org<mailto:voicemail@yyyyy.org>>
To: <dmiller@yyyyy.org<mailto:dmiller@yyyyy.org>>
Cc:
Bcc:
Date: Wed, 22 Mar 2017 14:19:00 -0400
Subject: Voicemail Message (BARBER,DANIELLE > Adminissions) From:1111111111
IP Office Voicemail redirected message



Has anyone had to fight this yet? Any help would be appreciated..

Thanks!

 

[sizbut]

Google are being by the RFCs absolutely correct. If multiple addresses are put in the From field then a single address must be put in the Sender field. Avaya would have to use some rule like copying the first From into the Sender field and hope that's the right choice. The obvious workaround of course is to only have one From address.


Stuck in a never ending cycle of file copying.

 

[jamie77]

Would I be correct in saying you have a comma in the phones username or full name fields in the IPO?

This is not supported if so and will be the reason for your issue.

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer

 

[twitchy087]

I agree in that the obvious resolution would to not add the comma but I am not aware of a way to do so. This is all done automatically via the system. The caller ID passed from the caller is passed to the from field. This is also reflected in call history on the phones.

The extensions/users do not have commas. This is purely coming from the external caller. CNAM supports usage of commas but the system/email do not seem to match it..

Thanks for the input

 

[jamie77]

Ah, appologies, you are getting this name from external. We don't see this in the UK. The only way to get names is from internal or VoIP trunks.

Not sue I see a way around this.

I would raise a ticket and ask Avaya. If the CNAM RFC supports commas, clearly emails don't, then Avaya would need to address this I would think.

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer

 

[sizbut]

Okay, if the incoming caller name is 'BARBER,DANIELLE' then if Avaya are being wrong to split that into two addresses (especially if as in your example they then put them in two different domains!).

Commas are allowed in the local part of email addresses, but they must be enclosed in quotes. If they were just passing that through as received that would again cause Google to reject the email. The challenge there is that Avaya would have to process the caller name for a range of special characters to ensure it was valid for email and would be at the same time be possibly making it not valid for a return message to its source.

Stuck in a never ending cycle of file copying.

 

[twitchy087]

Yea, everything seems to keep sending me back to opening a ticket with Avaya to fix the behavior. I have been trying to bypass that option as they are a real pest to work with.

I guess I will bite the bullet and get them involved.

Thanks everyone