Email được gửi đến miền Gmail đột nhiên không tuân thủ RFC 2822, Có thể bỏ qua với Google Apps không?


10

Bốn ngày trước, các email được gửi đến tài khoản Gmail của chúng tôi thông qua các dịch vụ thư của ISP của chúng tôi đã bắt đầu bị từ chối do không phải là người khiếu nại RFC 2822.

Các tin nhắn sau đây là không thể gửi được. Lý do của sự cố:
5.3.0 - Sự cố hệ thống thư khác 550-'5.7.1 [2001: 44b8: 8060: ff02: 300: 1: 6: 6 11] Hệ thống của chúng tôi đã phát hiện ra rằng \ n5.7.1 thông báo này là không tuân thủ RFC 2822 . Để giảm lượng thư rác \ n5.7.1 được gửi tới Gmail, thư này đã bị chặn. Vui lòng xem lại thông số kỹ thuật \ n5.7.1 RFC 2822 để biết thêm thông tin.
iw4si27447595pac.153 - GSMtp '

Thật là bực bội vì những email này đã hoạt động tốt trong hơn một năm qua. Tôi cho rằng Google đã tăng các bộ lọc của họ trong tuần trước.

Địa chỉ email chúng tôi đang cố gắng gửi thuộc về tài khoản Google Apps for Business của chúng tôi. Tôi đang tự hỏi, có cách nào để ghi đè bộ lọc tuân thủ RFC 2822 để cho phép các email đi qua không?

Cho đến nay, việc thêm tên miền ISP vào danh sách trắng spam trong cài đặt Gmail (trong bảng điều khiển Ứng dụng) vẫn chưa hoạt động.


Nhật ký telnet cho tin nhắn bị từ chối trong câu hỏi là:

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

Đáng lưu ý rằng máy gửi email không có khả năng thêm máy chủ smtp yêu cầu mật khẩu, vì vậy chúng tôi phải sử dụng máy chủ ISP của chúng tôi ...
OrangeBox

Câu trả lời:


12

RFC2822 cho biết Ngày: và Từ: tiêu đề là bắt buộc (phần 3.6). Dường như Google sẽ cho phép bạn thoát khỏi việc chỉ cần thêm tiêu đề From :, ví dụ:

[..]
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 

ahh, cảm ơn bạn sẽ phải xem liệu nhà phát triển phần mềm có thể thực hiện thay đổi này không. Bạn có biết nếu có thể ghi đè các bộ lọc phía máy chủ thư Gmails khi sử dụng Gapps không?
OrangeBox

6

Theo dõi trùng lặp Từ: tiêu đề hoặc Trả lời: các tiêu đề không khớp với nhau. Vấn đề tương tự cũng xảy ra với một số người dùng Outlook cho Mac, những người có thêm thông tin tiêu đề được di chuyển nhầm từ các tài khoản ứng dụng thư khách trước đó. Xem http://hintsforums.macworld.com/showthread.php?p=718579


Cảm ơn câu trả lời! Tôi đã bỏ phiếu nhưng không được chấp nhận vì tôi hy vọng tìm được cách ghi đè bộ lọc khi chúng tôi đang sử dụng Google Apps cho doanh nghiệp. Có suy nghĩ gì không?
OrangeBox

@OrangeBox Tôi không nghĩ có một tùy chọn, nhưng tại sao không gửi yêu cầu phản hồi với Google ?
poolie

Một điều thú vị là nhiều Fromtiêu đề đã được RFC822 cho phép, nhưng không được RFC2822 cho phép nữa (xuất bản 2001).
poolie

1

Tôi có một tập lệnh PHP gửi thông báo mỗi ngày, với các trường được xây dựng từ cơ sở dữ liệu. Ở cuối mỗi trường, lập trình viên đã sử dụng \r\nđể kết thúc các dòng (cả ký tự trả về vận chuyển và ký tự nguồn cấp dữ liệu). Điều này không có ý nghĩa gì, nhưng nó đã hoạt động cho đến bây giờ.

Tôi lấy ra \rnhân vật và đột nhiên các thư của tôi hiện đang tuân thủ RFC 2822.


1

Đây là một lỗi bất cứ điều gì đang làm xác nhận. Về mặt lý thuyết, RFC 822 cho phép các ký tự CR và LF riêng biệt, không phải là kết thúc dòng, nhưng RFC 2822 loại bỏ tính năng này. RFC 2822 phần 2.3 cho biết "CR và LF PHẢI chỉ xảy ra cùng nhau dưới dạng CRLF; chúng KHÔNG PHẢI xuất hiện độc lập trong cơ thể."

Những gì lập trình viên đã làm là khiếu nại RFC 2822 và phiên bản của bạn thì không. Là nhà phát triển, tôi thích các nguồn cấp dữ liệu một dòng nhưng sử dụng CRLF trong email là một yêu cầu tuyệt đối. Lý tưởng nhất là MUA sẽ hiểu bất kỳ kết thúc dòng hợp lý.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.