Mozilla 도움말 검색

고객 지원 사기를 피하세요. 저희는 여러분께 절대로 전화를 걸거나 문자를 보내거나 개인 정보를 공유하도록 요청하지 않습니다. "악용 사례 신고"옵션을 사용하여 의심스러운 활동을 신고해 주세요.

Learn More

Gmail RFC-5321 issue, fails to send emails

  • 3 답장
  • 2 이 문제를 만남
  • 465 보기
  • 최종 답변자: 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?

선택된 해결법

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

문맥에 따라 이 답변을 읽어주세요 👍 0

모든 댓글 (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

선택된 해결법

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.