Điểm:0

Postfix From: address có tuân thủ RFC cho các công việc định kỳ không?

lá cờ cn

Tôi có một máy chủ Ubuntu 18.04 với Postfix được định cấu hình để gửi qua chuyển tiếp thư mạng cục bộ.

Chỉ khi một tin nhắn được tạo bởi cron nó có bao gồm những điều sau đây trong Từ: tiêu đề:

Từ: [email protected] (Cron Daemon)

Tất cả các tin nhắn khác từ máy chủ như mong đợi:

Từ: [email protected]

Điều này gây ra sự cố cho việc ký DKIM chuyển tiếp và dường như không phù hợp với RFC 5322. Việc đọc của tôi về 3.4Phụ lục A.5 đó là địa chỉ rất có thể phải là:

Từ: <[email protected]> (Cron Daemon)

Tuy nhiên, tôi có thể hiểu nhầm RFC và có một số vấn đề khác.

Đây là cấu hình hiện tại, hầu như chỉ là cấu hình "vệ tinh" mặc định được tạo bởi hậu tố bưu kiện:

postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = không
biff = không
mức độ tương thích = 2
inet_interfaces = chỉ lặp lại
inet_protocols = ipv4
hộp thư_size_limit = 0
mydestination = $myhostname, relayclient.example.com, localhost.example.com, localhost
myhostname = relayclient.example.com
mạng của tôi = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = không
người nhận_delimiter = +
máy chủ chuyển tiếp = 192.0.2.85
smtp_tls_security_level = có thể
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = có

con mèo/etc/bí danh:

# Xem man 5 bí danh để biết định dạng
quản lý bưu điện: root
gốc: [email protected]

con mèo/etc/tên thư:

relayclient.example.com
lá cờ jp
Tại sao bạn nghĩ rằng nó "không phù hợp với RFC"?
Paul avatar
lá cờ cn
Hiểu biết của tôi về [RFC 5322](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.4) là nó phải là `Cron Daemon , nhưng cũng có thể là `` hoặc `[email protected]`.
lá cờ jp
Kiểm tra phụ lục RFC 5322 để biết ví dụ về nhận xét.
Paul avatar
lá cờ cn
Tôi vừa xem lại phần phụ lục và có vẻ như tất cả các ví dụ đều phù hợp với hiểu biết hiện tại của tôi. Có phải bằng cách nào đó tôi đã bỏ lỡ một cái mà bạn đang nghĩ đến?
Paul avatar
lá cờ cn
@AlexD Được rồi, vậy [A.5](https://www.rfc-editor.org/rfc/rfc5322.html#appendix-A.5) đưa ra các ví dụ như: `John (bạn thân của tôi); (cuối nhóm)`, nhưng ngay cả trong ví dụ đó, địa chỉ nằm trong ``, nhưng địa chỉ trong thư được tạo từ các công việc định kỳ thì không.
Nikita Kipriyanov avatar
lá cờ za
(...) là một phần "CFWS" từ thông số kỹ thuật. Xem [3.2.2. Gấp khoảng trắng và nhận xét](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.2.2)
Điểm:1
lá cờ za

Lưu ý thông số kỹ thuật cũng bao gồm bình luận:

Chuỗi ký tự đặt trong ngoặc đơn được coi là chú thích miễn là chúng không xuất hiện trong một "chuỗi trích dẫn", như được định nghĩa trong mục 3.2.4. Nhận xét có thể lồng vào nhau.

Có một số nơi trong đặc điểm kỹ thuật này mà chú thích và FWS có thể được chèn tự do. Để phù hợp với cú pháp đó, một bổ sung mã thông báo cho "CFWS" được xác định cho những nơi mà nhận xét và/hoặc FWS có thể xảy ra.

EBNF (Tôi đã sử dụng các mã thông báo không liên quan):

địa chỉ = hộp thư/nhóm
hộp thư = tên-addr / addr-spec
name-addr = [tên hiển thị] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
tên hiển thị = cụm từ

FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
ctext = %d33-39 / ; Có thể in US-ASCII
                    %d42-91 / ; nhân vật không bao gồm
                    %d93-126 / ; "(", ")", hoặc "\"
                    obs-ctext
ccontent = ctext/cặp trích dẫn/bình luận
bình luận = "(" *([FWS] ccontent) [FWS] ")"
CFWS = (1*([FWS] bình luận) [FWS]) / FWS

Lưu ý bình luận mã thông báo bao gồm dấu ngoặc đơn và CFWS có thể là nhận xét này (có khoảng trắng xung quanh) hoặc chính khoảng trắng đó. Phần này trong dấu ngoặc đơn xuất hiện ngay ở cuối góc-thêm mã thông báo, nơi nhận xét được cho phép. Vì vậy, điều này (Cron daemon) là một CFWS, "bình luận hoặc gấp khoảng trắng" mã thông báo, và do đó địa chỉ như chính tả hoàn toàn phù hợp với thông số kỹ thuật.

Cũng có một lưu ý đặc biệt về khỏa thân addr-spec với bình luận:

Lưu ý: Một số triển khai kế thừa đã sử dụng biểu mẫu đơn giản trong đó addr-spec xuất hiện mà không có dấu ngoặc nhọn, nhưng bao gồm tên của người nhận trong ngoặc đơn như một bình luận sau addr-spec. Vì ý nghĩa của thông tin trong một bình luận là không được chỉ định, việc triển khai NÊN sử dụng dạng tên-adr đầy đủ của hộp thư, thay vì biểu mẫu kế thừa, để chỉ định màn hình tên được liên kết với một hộp thư. Ngoài ra, vì một số di sản triển khai diễn giải nhận xét, nhận xét nói chung NÊN KHÔNG được sử dụng trong các trường địa chỉ để tránh gây nhầm lẫn như vậy triển khai.

Paul avatar
lá cờ cn
Trời ạ, có một thứ tôi thực sự thiếu sót ở đây, bởi vì khi tôi đọc nó, tôi thấy `[CFWS] "" [CFWS] /obs-angle-addr` và các thông báo từ các công việc định kỳ giống như `addr-spec [ CFWS]`, điều này có vẻ không giống với tôi.
lá cờ jp
Câu trả lời thực sự nằm trong Lưu ý về biểu mẫu địa chỉ kế thừa trong phần 3.4 của RFC 5322
Nikita Kipriyanov avatar
lá cờ za
Thật. Tôi đọc sai câu hỏi. Tuy nhiên, lưu ý đó là câu trả lời chính xác cho câu hỏi.
Paul avatar
lá cờ cn
Khi nó ghi "...tên của người nhận trong ngoặc đơn" là `(Cron Daemon)` người nhận? Có vẻ như trình nền tạo ra thông báo.
Nikita Kipriyanov avatar
lá cờ za
Và sau đó: "... ý nghĩa của thông tin trong một bình luận là không xác định...". Tôi nghĩ rằng đó chỉ là một từ ngữ tồi khi gọi thứ đó trong ngoặc đơn là "tên của người nhận" đã vô tình thêm một ý nghĩa.
Paul avatar
lá cờ cn
Thật vậy, có vẻ như từ ngữ kém. Khi đọc lại, tôi nghĩ nó có nghĩa là "một số triển khai kế thừa [một ví dụ về cách sử dụng kế thừa]...".
lá cờ jp
@Paul việc sử dụng định dạng `[email protected] (Tên người dùng)` là phổ biến (`mutt` hoặc `mail` vẫn hiểu) nhưng, về mặt cú pháp, nội dung trong ngoặc đơn chỉ là một nhận xét và cách sử dụng của nó là 'Tên hiển thị' ' của người gửi hoặc người nhận không được chỉ định trong tiêu chuẩn.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.