Bản ghi SPF là gì và làm cách nào để định cấu hình chúng?


49

Đây là một câu hỏi kinh điển về việc thiết lập các bản ghi SPF .

Tôi có một văn phòng có nhiều máy tính chia sẻ một ip bên ngoài (Tôi không chắc địa chỉ đó là tĩnh hay động). Mỗi máy tính kết nối với máy chủ thư của chúng tôi thông qua IMAP bằng triển vọng. Email được gửi và nhận bởi những máy tính đó, và một số người dùng cũng gửi và nhận email trên điện thoại di động của họ.

Tôi đang sử dụng http://wizard.easyspf.com/ để tạo bản ghi SPF và tôi không chắc chắn về một số trường trong trình hướng dẫn, cụ thể:

  1. Nhập bất kỳ tên miền nào khác có thể gửi hoặc chuyển tiếp thư cho tên miền này
  2. Nhập bất kỳ địa chỉ IP nào ở định dạng CIDR cho netblocks có nguồn gốc hoặc chuyển tiếp thư cho miền này
  3. Nhập bất kỳ máy chủ lưu trữ nào khác có thể gửi hoặc chuyển tiếp thư cho miền này
  4. Làm thế nào nghiêm ngặt MTA nhận thức điều trị này?

một vài câu hỏi đầu tiên tôi khá chắc chắn về ... hy vọng tôi đã cung cấp đủ thông tin.

Câu trả lời:


68

Bản ghi SPF chi tiết máy chủ nào được phép gửi thư cho miền của bạn.

Câu hỏi 1-3 thực sự tóm tắt toàn bộ quan điểm của SPF: Bạn nên liệt kê địa chỉ của tất cả các máy chủ được phép gửi thư đến từ miền của bạn.
Nếu bạn không có một danh sách đầy đủ tại thời điểm này, nói chung không nên thiết lập một bản ghi SPF. Ngoài ra, một tên miền chỉ có thể có một bản ghi SPF, vì vậy bạn sẽ cần kết hợp tất cả thông tin vào một bản ghi.

Các câu hỏi cá nhân thực sự chỉ giúp phá vỡ danh sách cho bạn.

  1. yêu cầu bạn cho các tên miền khác mà máy chủ thư có thể chuyển tiếp thư từ bạn; nếu bạn có một máy chủ MX phụ tại mail-relay.example.org và đó là máy chủ thư chính (bản ghi MX) cho tên miền example.org, thì bạn nên nhập mx:example.org. Bản ghi SPF của bạn phải bao gồm bản ghi MX của tên miền của bạn trong gần như mọi trường hợp ( mx).
  2. yêu cầu bạn cho netblocks ip của bạn. Nếu bạn có máy chủ colocated tại 1.2.3.0/28 và không gian địa chỉ văn phòng của bạn là 6.7.8.0/22, hãy nhập ip4:1.2.3.0/28 ip4:6.7.8.0/22. Không gian IPv6 nên được thêm vào như ví dụ ip6:2a01:9900:0:4::/64.
  3. nếu (ví dụ) bạn cũng có một máy tắt trong văn phòng của người khác phải được phép gửi thư từ tên miền của bạn, hãy nhập nó, ví dụ như a:mail.remote.example.com.

Người dùng điện thoại di động của bạn có vấn đề. Nếu họ gửi email bằng cách kết nối với máy chủ thư của bạn bằng cách sử dụng SMTP AUTH và gửi qua máy chủ đó, thì bạn đã xử lý chúng bằng cách liệt kê địa chỉ của máy chủ thư trong (2). Nếu họ gửi email bằng cách chỉ kết nối với bất cứ điều gì mail server cung cấp các nhà cung cấp của 3G / HSDPA, sau đó bạn có thể không làm SPF có ý nghĩa cho đến khi bạn đã tái xây dựng lại cơ sở hạ tầng email của bạn để bạn làm kiểm soát tất cả các điểm mà từ đó email dường như là từ bạn chạm Internet.

Câu hỏi 4 hơi khác một chút và hỏi người nhận nên làm gì với email tuyên bố là từ miền của bạn không đến từ một trong các hệ thống được liệt kê ở trên. Có một số câu trả lời hợp pháp, nhưng những câu trả lời thú vị duy nhất là ~all(thất bại mềm) và -all(thất bại cứng). ?all(không có câu trả lời) cũng vô dụng như ~all(qv), và +alllà một sự gớm ghiếc.

~alllà sự lựa chọn đơn giản; nó nói với mọi người rằng bạn đã liệt kê một loạt các hệ thống được ủy quyền để gửi thư từ bạn, nhưng bạn không cam kết danh sách đó là đầy đủ, vì vậy thư từ miền của bạn đến từ các hệ thống khác vẫn có thể hợp pháp. Tôi mong bạn không làm điều đó. Nó không chỉ làm cho SPF hoàn toàn vô nghĩa, mà một số quản trị viên thư trên SF còn cố tình định cấu hình máy thu SPF của họ để coi ~alllà huy hiệu của người gửi thư rác. Nếu bạn không định làm gì -all, đừng bận tâm đến SPF .

-alllà sự lựa chọn hữu ích; nó nói với mọi người rằng bạn đã liệt kê các hệ thống được phép gửi email từ bạn và không có hệ thống nào khác được phép làm như vậy, vì vậy họ có thể từ chối email từ các hệ thống không được liệt kê trong bản ghi SPF của bạn. Đây là điểm của SPF, nhưng bạn phải chắc chắn rằng bạn đã liệt kê tất cả các máy chủ được ủy quyền để tạo hoặc chuyển tiếp thư từ bạn trước khi bạn kích hoạt nó .

Google được biếtkhuyên rằng

Xuất bản bản ghi SPF sử dụng -all thay vì ~ tất cả có thể dẫn đến các vấn đề giao hàng.

tốt, vâng, nó có thể; đó là toàn bộ điểm SPF . Chúng tôi không thể biết chắc chắn tại sao google đưa ra lời khuyên này, nhưng tôi cực kỳ nghi ngờ rằng đó là để ngăn chặn những người quản trị hệ thống không biết chính xác email của họ bắt nguồn từ việc gây ra vấn đề giao hàng. Nếu bạn không biết tất cả email của mình đến từ đâu, đừng sử dụng SPF . Nếu bạn đang sử dụng SPF, hãy liệt kê tất cả các địa điểm xuất phát và nói với thế giới rằng bạn tự tin trong danh sách đó -all.

Lưu ý rằng không ai trong số này ràng buộc trên máy chủ của người nhận; thực tế là bạn quảng cáo một bản ghi SPF theo cách không bắt buộc ai khác phải tôn vinh nó. Tùy thuộc vào quản trị viên của bất kỳ máy chủ thư cụ thể nào mà email họ chọn chấp nhận hoặc từ chối. Những gì tôi nghĩ SPF làm là cho phép bạn từ chối mọi trách nhiệm hơn nữa đối với email được cho là từ miền của bạn, nhưng không phải vậy. Bất kỳ quản trị viên thư nào đến gặp bạn đều phàn nàn rằng tên miền của bạn đang gửi cho họ thư rác khi họ không muốn kiểm tra bản ghi SPF mà bạn quảng cáo sẽ nói với họ rằng email nên bị từ chối có thể được gửi đi bằng một con bọ chét trong tai họ.


Vì câu trả lời này đã được chuẩn hóa, tốt hơn tôi nên nói một vài từ về includeredirect. Cái sau đơn giản hơn; nếu bản ghi SPF của bạn, giả sử example.com, nói redirect=example.org, thì example.orgbản ghi SPF thay thế cho bản ghi của bạn. example.orgcũng được thay thế cho tên miền của bạn trong các lần tra cứu đó (ví dụ: nếu example.orgbản ghi của nó bao gồm mxcơ chế, việc MXtra cứu nên được thực hiện example.orgchứ không phải trên miền của chính bạn).

includebị hiểu lầm rộng rãi, và như các tác giả của tiêu chuẩn lưu ý " tên 'bao gồm' được lựa chọn kém ". Nếu bản ghi includecủa bản ghi SPF của bạn example.org, thì example.orgbản ghi của người nhận nên được kiểm tra để xem liệu nó có đưa ra bất kỳ lý do nào (bao gồm +all) để chấp nhận email của bạn không . Nếu có, thư của bạn sẽ vượt qua. Nếu không, người nhận nên tiếp tục xử lý bản ghi SPF của bạn cho đến khi hạ cánh trên allcơ chế của bạn . Do đó, -allhoặc thực sự là bất kỳ việc sử dụng nào khác allngoại trừ +all, trong một includebản ghi d, không ảnh hưởng đến kết quả xử lý.

Để biết thêm thông tin về các bản ghi SPF http://www.openspf.org là một tài nguyên tuyệt vời.


Xin đừng hiểu sai cách này, nhưng nếu bạn nhận được một bản ghi SPF sai, bạn có thể ngăn một phần đáng kể của internet nhận email từ bạn cho đến khi bạn sửa nó. Câu hỏi của bạn cho thấy bạn có thể không hoàn toàn au fait với những gì bạn đang làm, và nếu đó là trường hợp, sau đó bạn có thể muốn xem xét việc nhận hỗ trợ chuyên nghiệp trước khi bạn làm điều gì đó mà dừng lại bạn gửi email đến một awful nhiều người.

Chỉnh sửa : cảm ơn bạn vì những lời tốt đẹp của bạn, họ được đánh giá cao.

SPF chủ yếu là một kỹ thuật để ngăn chặn joe-jobbing , nhưng một số người dường như đã bắt đầu sử dụng nó để cố gắng phát hiện thư rác. Một số trong số đó thực sự có thể gắn một giá trị âm với việc bạn không có bản ghi SPF nào cả, hoặc bản ghi vượt mức (ví dụ a:3.4.5.6/2 a:77.5.6.7/2 a:133.56.67.78/2 a:203.54.32.1/2, khá lén lút tương đương +all), nhưng điều đó tùy thuộc vào họ và bạn không thể làm gì nhiều về nó.

Cá nhân tôi nghĩ rằng SPF là một điều tốt và bạn nên quảng cáo một bản ghi nếu cấu trúc thư hiện tại của bạn cho phép, nhưng rất khó để đưa ra một câu trả lời có thẩm quyền, hợp lệ cho toàn bộ internet, về cách mọi người đang sử dụng bản ghi DNS được thiết kế cho mục đích cụ thể, khi họ quyết định sử dụng nó cho một mục đích khác. Tất cả tôi có thể nói một cách chắc chắn là nếu bạn làm quảng cáo một bản ghi SPF với một chính sách -all, và bạn nhận được nó sai, rất nhiều người sẽ không bao giờ thấy mail của bạn.

Chỉnh sửa 2 : đã xóa theo bình luận và để cập nhật câu trả lời.


đánh giá cao câu trả lời thấu đáo và đơn giản (mà tôi rõ ràng là cần thiết). bạn đã đúng khi lưu ý rằng tôi chủ yếu ở trong bóng tối và không có doanh nghiệp đội mũ bưu điện. một câu hỏi tiếp theo: vì chúng ta đang nói về một hoạt động rất nhỏ (tổng cộng khoảng 10-15 tài khoản email) - và không gửi khối lượng lớn thư - đây có phải là thứ chúng ta có thể tồn tại mà không cần đến lúc này, hoặc có thể sẽ cuối cùng trong rất nhiều thư mục thư rác? khi chúng tôi gửi thư hàng loạt, chúng tôi sử dụng các dịch vụ như mailchimp, v.v.
Vulgarbulgar

~ Tất cả đều tốt cho hai điều: Kịch bản 1."không hoàn toàn au fait " mà bạn mô tả. Nó cho phép bạn thực hiện tất cả các thiết lập theo cách thực tế, bao gồm cả thử nghiệm thực tế, trước khi kéo trình kích hoạt cuối cùng. 2.Điểm thư rác. Nếu bạn thực sự không thể kiểm soát tất cả các điểm thoát thư của mình, ~ tất cả đều có thể giúp điểm spam cho những hệ thống phù hợp với hồ sơ của bạn (tất nhiên: chúng cũng có thể làm tổn thương điểm số đối với những hệ thống bị lỗi mềm).
Joel Coel

Họ cũng có thể làm tổn thương điểm số với các hệ thống người nhận có quản trị viên coi ~alllà chỉ báo spam trên toàn bộ miền, trong đó có ít nhất một điểm trên SF.
MadHatter

2
@MadHatter Một bình luận cho Edit2 cụ thể: Các SPF đặc tả hiện nay nói rằng bạn phải sử dụng một trong hai TXThoặc SPFnhưng điều đó bạn nên sử dụng cả hai (giống hệt nhau), đề xuất SPF sắp tới đặc tả từ bỏ SPFnhư hấp thu đã được ít hơn dự kiến và chủ yếu chỉ gây ra vấn đề tương thích. Với ý nghĩ đó, có vẻ như không nên chỉ nhìn lên SPF.
Håkan Lindqvist

3
Cảm ơn sự thật và tôi đã cười lớn tiếng "+ tất cả là một sự gớm ghiếc".
jerclarke

3

Điều quan trọng cho thiết lập của bạn là cấu hình của máy chủ cuối cùng sẽ gửi email đến internet. Bạn nói rằng bạn gửi email qua SMTP. Vì vậy, về mặt địa chỉ IP, vấn đề quan trọng là cấu hình máy chủ SMTP của bạn (câu hỏi 2)

Nếu bạn đang sử dụng một bên thứ ba, chẳng hạn như gmail, để gửi email của mình, bạn phải bao gồm các bản ghi spf của họ như thế này: bao gồm: _spf.google.com (trình hướng dẫn ajax dường như không biết về điều này).

Đối với "Làm thế nào nghiêm ngặt", hãy để lại "lỗi mềm" (~ tất cả) nếu bạn không chắc chắn, nhưng "từ chối" khác (-all) là cách để đi khi cấu hình của bạn sạch sẽ.

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.