Електронні листи, надіслані до домену Gmail, раптом не відповідають стандартам RFC 2822. Можливо, обхід Google Apps?

Чотири дні тому електронні листи, надіслані до наших облікових записів Gmail через поштові сервіси нашого провайдера, почали відхилятися через те, що він не був скаржником RFC 2822.

Наведене нижче повідомлення було недоставлене. Причина проблеми:
5.3.0 - Інша проблема з поштовою системою 550 -5.5.1 [2001: 44b8: 8060: ff02: 300: 1: 6: 6 11] Наша система виявила, що \ n5.7.1 це повідомлення не відповідає стандарту RFC 2822 . Щоб зменшити кількість спаму \ n5.7.1, надісланого Gmail, це повідомлення було заблоковано. Для отримання додаткової інформації перегляньте \ n5.7.1 специфікації RFC 2822.
iw4si27447595pac.153 - gsmtp '

Це засмучує те, що ці електронні листи працюють добре протягом більше року - я припускаю, що Google останній тиждень підвищив свої фільтри.

Електронна адреса, яку ми намагаємося надіслати, належить до нашого облікового запису Google Apps for Business. Мені цікаво, чи існує спосіб змінити фільтр відповідності RFC 2822, щоб дозволити електронному листу надходити?

Поки додавання доменного імені провайдерів до списку спаму в налаштуваннях Gmail (на панелі керування додатків) не працює.

Журнал telnet для відхиленого повідомлення, про який йдеться, такий:

220-ipmail06.adl6.xxxxx.net ESMTP 220 ESMTP; eth2958.xxx.adsl.OurISP.net [150.xxx.xxx.xx1] in MTA
HELO WINDOWS-xxxxx (<- this is our server name) 
250 ipmail06.adl6.OurISP.net 
MAIL FROM: account@OurISP.net
250 sender ok 
RCPT TO: admin@googleappsdomain.com
250 recipient ok 
RCPT TO: admin@DifferentGoogleAppsDomain.com
250 recipient ok 
DATA 
354 go ahead 
Subject: Test email from the Avid ISIS Notification Application This message was generated by Avid ISIS Notification Application. . 
QUIT 
250 ok: Message 716893804 accepted

RFC2822 говорить дата: і Від: потрібні заголовки (розділ 3.6). Схоже, Google дозволить вам уникнути, просто додавши заголовок From: хоча, наприклад:

[..]
DATA 
354 go ahead 
From: <account@OurISP.net>   <-- add this
Subject: Test email from the Avid ISIS Notification Application This message was generated by Avid ISIS Notification Application.
.
QUIT 
250 ok: Message 716893804 accepted 

Слідкуйте за дублікатами від: заголовки або відповіді: заголовки, які не відповідають одна одній. Цю ж проблему зазнали деякі користувачі Outlook для Mac, у яких додаткова інформація заголовка помилково переміщена з попередніх облікових записів поштових клієнтів. Дивіться сторінку http://hintsforums.macworld.com/showthread.php?p=718579

У мене є скрипт PHP, який щодня надсилає сповіщення із полями, побудованими з бази даних. В кінці кожного поля програміст \r\nзакінчував лінії (як символи повернення каретки, так і символи подачі рядків). Це не має сенсу, але воно працювало досі.

Я вивів \rперсонажа і раптом мої листи тепер сумісні з RFC 2822.

Ця помилка все, що робить перевірку. RFC 822 теоретично допускає окремі символи CR та LF, які не є лінією кінців, але RFC 2822 видаляє цю функцію. У розділі 2.3 RFC 2822 написано: "CR та LF ОБОВ'ЯЗКОВО виникають разом як CRLF; вони НЕ МОЖУТЬ з'являтися незалежно в організмі".

Програміст зробив скаргу RFC 2822, а ваша версія - ні. Як розробник, я віддаю перевагу однорядним каналам, але використання CRLF в електронній пошті є абсолютною вимогою. В ідеалі MUA зрозуміє будь-які розумні межі рядка.