Письма, отправленные на домен Gmail, неожиданно не соответствуют RFC 2822. Возможно ли обойтись с помощью Google Apps?

10

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

Следующее сообщение было невозможно доставить. Причина проблемы:
5.3.0 - Другая проблема почтовой системы 550-'5.7.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 для бизнеса. Мне интересно, есть ли способ переопределить фильтр соответствия 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

gmail google-apps spam-prevention

— OrangeBox
источник

Стоит отметить, что машина, отправляющая электронные письма, не имеет возможности добавлять SMTP-серверы, которым требуется пароль, поэтому мы должны использовать сервер нашего интернет-провайдера ...

— OrangeBox

12

RFC2822 говорит, что требуются заголовки Date: и From: (раздел 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

— вероятно
источник

ааа, спасибо, мне придется посмотреть, сможет ли разработчик программного обеспечения внести это изменение. Знаете ли вы, можно ли переопределить фильтры на стороне почтового сервера Gmails при использовании Gapps?

— OrangeBox

6

Следите за дублированием заголовков From: или заголовков Reply-to:, которые не соответствуют друг другу. Эта же проблема возникла у ряда пользователей Outlook для Mac, у которых была дополнительная информация заголовка, ошибочно перенесенная из предыдущих учетных записей почтовых клиентов. См. Http://hintsforums.macworld.com/showthread.php?p=718579.

— Стив Хоге
источник

Спасибо за ответ! Я проголосовал, но не принял, потому что надеюсь найти способ переопределить фильтр, поскольку мы используем Google Apps для бизнеса. Какие-нибудь мысли?

— OrangeBox

@OrangeBox Я не думаю, что есть вариант, но почему бы не подать запрос обратной связи в Google ?

— пул

Одна интересная вещь - то, что многократные Fromзаголовки были разрешены RFC822, но больше не разрешены RFC2822 (изданный 2001).

— пул

1

У меня есть PHP-скрипт, который отправляет уведомления каждый день, с полями, построенными из базы данных. В конце каждого поля программист использовал \r\nдля окончания строк (как символы возврата каретки, так и символы перевода строки). Это не имеет никакого смысла, но это работало до сих пор.

Я достал \rперсонажа, и вдруг мои письма теперь соответствуют RFC 2822.

— user2375103
источник

1

Это ошибка, что делает проверку. RFC 822 теоретически допускает отдельные символы CR и LF, которые не являются концами строки, но RFC 2822 удаляет эту функцию. В разделе 2.3 RFC 2822 говорится, что «CR и LF ДОЛЖНЫ встречаться только вместе как CRLF; они НЕ ДОЛЖНЫ появляться в теле независимо».

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

— Дункан Симпсон
источник