DMARC - hiểu báo cáo tổng hợp


8

TL; DR
Tôi nhận được rất nhiều phản hồi DMARC từ các tài khoản / trang web mà tôi không liên hệ và muốn rõ ràng hơn nếu tôi nên thực hiện bất kỳ hành động nào hoặc nếu các báo cáo phản hồi này có thông tin về bất kỳ vấn đề nghiêm trọng nào không?

Tôi chạy một máy chủ WHM và sử dụng SPF và DKIM (và _DMARC), tất cả các email được gửi từ cùng một máy chủ tên miền.

Một ví dụ thiết lập DNS cho _DMARC của tôi (và DKIM và SPF):

mydomain.co.uk     14400 IN TXT "v=spf1 mx a ip4:11.22.33.44 ip4:11.22.33.55 ~all"

default._domainkey 14400 IN TXT "v=DKIM1; k=rsa; p=<code>;

_dmarc             14400 IN TXT "v=DMARC1; p=quarantine; sp=none; 
                                rua=mailto:me@mydomain.co.uk!90m; 
                                ruf=mailto:me@mydomain.co.uk; 
                                rf=afrf; pct=100; ri=86400"

và theo như tôi có thể nói điều này được thiết lập và hoạt động như mong đợi.

tuy nhiên, tôi nhận được khá nhiều tin nhắn tự động từ nhiều miền khác nhau trên toàn thế giới, không liên quan gì đến tên miền của tôi. Tôi là người duy nhất sử dụng email từ tên miền của tôi, không ai khác gửi email từ tên miền của tôi.

Ví dụ: sáng nay tôi đã nhận được báo cáo tổng hợp DMARC từ Comcast nêu rõ:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
    <version>1.0</version>
    <report_metadata>
        <org_name>comcast.net</org_name>
        <email>dmarc-admin@alerts.comcast.net</email>
        <report_id>v1-1483425166-mydomain.co.uk</report_id>
        <date_range>
            <begin>1483315200</begin>
            <end>1483401600</end>
        </date_range>
    </report_metadata>
    <policy_published>
        <domain>mydomain.co.uk</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>quarantine</p>
        <sp>none</sp>
        <pct>100</pct>
        <fo>0</fo>
    </policy_published>
    <record>
        <row>
            <source_ip>72.167.218.164</source_ip>
            <count>1</count>
            <policy_evaluated>
                <disposition>none</disposition>
                <dkim>fail</dkim>
                <spf>fail</spf>
            </policy_evaluated>
        </row>
        <identifiers>
            <header_from>mydomain.co.uk</header_from>
        </identifiers>
        <auth_results>
            <spf>
                <domain>bounce.secureserver.net</domain>
                <scope>mfrom</scope>
                <result>pass</result>
            </spf>
        </auth_results>
    </record>
</feedback>

Không, tôi không nhận ra bất kỳ chi tiết nào được nêu ở đây ngoài tên miền của mình, địa chỉ IP được cung cấp <source_ip>không phải là địa chỉ IP của tôi và tôi không biết có bất kỳ liên hệ nào với Comcast.

Về cơ bản, tôi nhận được khá nhiều thông báo này và tôi không thể tìm thấy bất kỳ phản hồi nào để cho tôi biết nếu chúng chỉ là thông tin và có thể bị lãng quên (trong trường hợp đó là điểm của chúng?) Hoặc nếu tôi có thể làm gì đó với máy chủ của tôi để cải thiện những thất bại mà thông báo cho tôi biết.

VÌ THẾ:

  • Là những báo cáo một cái gì đó có thể được hành động?
  • Làm thế nào các báo cáo DMARC như những báo cáo này sẽ được xử lý vào cuối của tôi?
  • Các báo cáo này có phải là chỉ số của bất kỳ hình thức thỏa hiệp tài khoản nào không
  • có thể / số lượng các báo cáo này [có khả năng] phản ánh không tốt đến tên miền của tôi với phần còn lại của 'web không?

Có thể đáng chú ý tôi nghi ngờ câu trả lời cho hai viên đạn cuối cùng là "Không", nhưng tôi không phải là chuyên gia về những viên đạn này.


Tôi đã đọc bài đăng này cũng như Câu hỏi thường gặp về DMARCchủ đề này , nhưng không có nhiều thông tin. về cách chúng tôi dự định phản ứng với các báo cáo tổng hợp. Tôi biết rằng các báo cáo DMARC "không thành công" có thể được gây ra bởi các chương trình chuyển tiếp thư, mặc dù tôi hy vọng sẽ phủ nhận khả năng này với SPF của mình ~all.

Nhìn chung, tôi nghĩ rằng tôi không cần phải lo lắng về các báo cáo này nhưng tôi muốn có ý kiến ​​thứ hai do những gì tôi cho là đều đặn và ( tôi nghĩ ) số lượng báo cáo tổng hợp tương đối đáng kể mà tôi nhận được.

Câu trả lời:


6

Là những báo cáo một cái gì đó có thể được hành động?

Có, nhưng hầu hết các thông tin sẽ hy vọng xác nhận tất cả là ổn với cấu hình của bạn.

Làm thế nào các báo cáo DMARC như những báo cáo này sẽ được xử lý vào cuối của tôi?

Thông thường, các báo cáo này sẽ được xử lý bởi một hệ thống tự động biến dữ liệu này thành các báo cáo đẹp với biểu đồ, số liệu thống kê và các vấn đề cần chú ý. Nếu bạn chưa thấy loại hệ thống này thì có lẽ bạn nên xem dmarcian.com , nơi cung cấp dịch vụ cơ bản miễn phí, giúp bạn bắt đầu và hiểu những gì bạn có thể và không thể làm hoặc nhìn thấy. Để làm việc này, bạn sẽ phải sử dụng một địa chỉ email mà họ cung cấp cho bạn trong hồ sơ DMARC của bạn.

Là những báo cáo chỉ số của bất kỳ hình thức thỏa hiệp tài khoản?

Không, chúng chỉ là báo cáo về tất cả hoạt động từ các máy chủ có khả năng DMARC đã xử lý các tin nhắn tự xưng là từ tên miền của bạn, về cơ bản cho bạn biết họ đã nhận được tin nhắn, nó đến từ đâu và họ đã làm gì với nó và tại sao.

Có thể / số lượng các báo cáo này [có khả năng] phản ánh không tốt về tên miền của tôi với phần còn lại của web không?

Không, các báo cáo này chỉ được gửi đến địa chỉ email được cung cấp trong hồ sơ DMARC và không được công bố trên web. Tiềm năng thực sự duy nhất cho tác động tiêu cực là nếu bạn thiết lập SPF và / hoặc DKIM của bạn sai và cuối cùng nhận được rất nhiều tin nhắn bị từ chối / chặn, nhưng ít nhất với DMARC bạn sẽ biết về nó.


Cảm ơn sự yên tâm đó. Tôi đã có một tài khoản (miễn phí) được thiết lập dmarcian.comnhưng tôi không chắc tại sao điều đó lại có ích như vậy, nhưng tôi đoán nó tóm tắt dữ liệu phản hồi mà báo cáo cung cấp cho tôi.
Martin

1
Nó chỉ dễ dàng hơn trong mắt, đặc biệt là khi số lượng dữ liệu trong các báo cáo cũng như tần suất nhận được chúng có thể là đáng kể. Các báo cáo DMARC được thiết kế để xử lý bằng máy tính, giao diện dmarcian.com đã được thiết kế để con người đọc. Bạn luôn có thể đưa ra giải pháp xử lý tự động của riêng mình nếu bạn không phải là người hâm mộ giao diện dmarcian.com. Những người khác tồn tại quá mà bạn có thể khám phá nhưng đây là người miễn phí duy nhất tôi biết. Hi vọng điêu nay co ich.
richhallstoke

2

Như một câu trả lời cho ví dụ của bạn: Nhiều lỗi DMARC có thể được truy ngược lại danh sách chuyển tiếp và gửi thư, ví dụ như với Google Groups for Business. Tuy nhiên, trong báo cáo, nó cho chúng ta thấy email đã được gửi từ một máy chủ lưu trữ, một phần của secureserver.net. Chỉ số SPF đã được kiểm tra trên đường trở về bounce.secureserver.netvà được thông qua.

Rất có thể đây là một tin nhắn bị trả lại từ dịch vụ chống SPAM hoặc SMTP gửi đến của bạn, được gửi lại cho người gửi email ban đầu, đã cố gắng gửi email cho bạn. Thư bị trả lại sẽ được gửi thay mặt bạn với đường dẫn trả lại đã thay đổi. SecureServer.net là một phần của GoDaddy, bạn đang lưu trữ với GoDaddy hoặc chi nhánh?

Như một câu trả lời cho tuyên bố của bạn:

Tôi biết rằng các báo cáo DMARC "không thành công" có thể được gây ra bởi các chương trình chuyển tiếp thư, mặc dù tôi hy vọng sẽ phủ nhận khả năng này với SPF của mình ~all.

DMARC sẽ chỉ đánh giá Đạt nếu kiểm tra SPF hoặc DKIM dẫn đến vượt qua, phù hợp với Frommiền địa chỉ của bạn . Vì vậy, tôi không chắc ý của bạn là gì mà ~allphủ nhận vấn đề.

Các nhà chuyển tiếp thường viết return-pathlại địa chỉ thoát của riêng họ, khiến nó không khớp với miền gốc. Th ARC giao thức vẫn còn trong dự thảo, nhưng nên phủ nhận vấn đề chuyển tiếp này cho sự liên kết SPF với DMARC cho giao nhận đáng tin cậy. Ngoài ra, chữ ký DKIM thường được giữ nguyên nhất, trừ khi các trường đã ký được sửa đổi bởi người chuyển tiếp. Vì vậy DMARC vẫn có thể vượt qua dựa trên DKIM.

Một điều cuối cùng:

Trong chính sách DMARC của bạn, bạn xuất bản sp=nonechính sách cho tất cả các tên miền phụ, nếu không sẽ kế thừa p=quarantinechính sách. Điều này dẫn đến việc bất cứ ai giả mạo tên miền của bạn chỉ có thể chọn bất kỳ tên miền phụ nào để sử dụng, chẳng hạn app.mydomain.co.uk. Có lẽ đây là một thiết lập mong muốn, nhưng tôi chỉ muốn chỉ ra nó.


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.