Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Gmail RFC-5321 issue, fails to send emails

  • 3 replies
  • 2 have this problem
  • 3 views
  • Last reply by Matt

more options

I'm using Gmail with TB 38.3.0 on MAC OSX 10.9.5. Over the past few days I've been repeatedly getting the following failure message:

"An error occurred while sending mail. The mail server responded: 5.1.2 The address specified is not a valid RFC-5321 address. y77sm17688366wme.15 - gsmtp. Please verify that your email address is correct in your account settings and try again"

It's coming from TB in an error dialogue message rather than from the Gmail mailer daemon.

I use a shadowed email address as we switched URL a while ago and couldn't change our mail settings.

It's becoming a real issue, I love TB and can't switch from gmail.......can anyone help?

I'm using Gmail with TB 38.3.0 on MAC OSX 10.9.5. Over the past few days I've been repeatedly getting the following failure message: "An error occurred while sending mail. The mail server responded: 5.1.2 The address specified is not a valid RFC-5321 address. y77sm17688366wme.15 - gsmtp. Please verify that your email address is correct in your account settings and try again" It's coming from TB in an error dialogue message rather than from the Gmail mailer daemon. I use a shadowed email address as we switched URL a while ago and couldn't change our mail settings. It's becoming a real issue, I love TB and can't switch from gmail.......can anyone help?

Chosen solution

Google roll out:

Hey all -

Yes, in the past week we've rolled out a change which enforced validation of the MAIL FROM argument to be a valid RFC 5321 email address.

This validation occurs across all SMTP servers Gmail operates, so for inbound MX servers, smtp.gmail.com MSA submission servers and GfW SMTP Relay servers. Previously, we were doing validation at later stages which could cause message bounces and other issues. This change pushed the validation to the first use so people are more aware of the issue.

For the MSA case (third party clients using smtp.gmail.com and user logins), we've rewritten the MAIL FROM to match one of the user's valid custom from addresses (or empty in the case of bounces) for a large number of years. This apparently has allowed folks to have mis-configuration that persisted for a long time. It also means that we're seeing a bunch of failures from third party devices like Samsung and Foscam cameras, and third party software like SyncBackup. We are likely to have to relax these requirements for the MSA case because of this, but the ETA for such a fix is maybe the end of this week or beginning of next week.

We are not planning on relaxing the requirements for MX and Relay, however. In those cases, we don't really have a good address to override to, and if we don't override them, the messages are incapable of bouncing, which can cause people to perceive delivery failures as message loss.

Also, a warning: we're thankful for the SMTP transaction traces that several people provided, but be warned that the transaction trace for an MSA transaction will contain authentication information that people can steal and use. Please remove or XXXX any long character strings in the AUTH portion of the log.

Thanks for the reports, and sorry for the confusion.

Brandon

Read this answer in context 👍 0

All Replies (3)

more options

So despite having dontated to mozilla no numerous occassions no one is going to help with this issue? I've tried reinstalling and googling the problem. Emails send fine from gmail, I realise this is probably a problem driven by google changes but surely someone can help with this issue?

more options

Chosen Solution

Google roll out:

Hey all -

Yes, in the past week we've rolled out a change which enforced validation of the MAIL FROM argument to be a valid RFC 5321 email address.

This validation occurs across all SMTP servers Gmail operates, so for inbound MX servers, smtp.gmail.com MSA submission servers and GfW SMTP Relay servers. Previously, we were doing validation at later stages which could cause message bounces and other issues. This change pushed the validation to the first use so people are more aware of the issue.

For the MSA case (third party clients using smtp.gmail.com and user logins), we've rewritten the MAIL FROM to match one of the user's valid custom from addresses (or empty in the case of bounces) for a large number of years. This apparently has allowed folks to have mis-configuration that persisted for a long time. It also means that we're seeing a bunch of failures from third party devices like Samsung and Foscam cameras, and third party software like SyncBackup. We are likely to have to relax these requirements for the MSA case because of this, but the ETA for such a fix is maybe the end of this week or beginning of next week.

We are not planning on relaxing the requirements for MX and Relay, however. In those cases, we don't really have a good address to override to, and if we don't override them, the messages are incapable of bouncing, which can cause people to perceive delivery failures as message loss.

Also, a warning: we're thankful for the SMTP transaction traces that several people provided, but be warned that the transaction trace for an MSA transaction will contain authentication information that people can steal and use. Please remove or XXXX any long character strings in the AUTH portion of the log.

Thanks for the reports, and sorry for the confusion.

Brandon

more options

Edd10183 said

So despite having dontated to mozilla no numerous occassions no one is going to help with this issue? I've tried reinstalling and googling the problem. Emails send fine from gmail, I realise this is probably a problem driven by google changes but surely someone can help with this issue?

I am pleased you finally worked out that the issue was with Gmail. But to correct your misapprehension here. Thunderbird is developed by a Community project managed by the Thunderbird council. Donations to Mozilla are not donations to Thunderbird since they ceased development. They announced this in July 2012.