Как вы можете убедиться, что электронное письмо было отправлено с правильного домена и что его содержимое не было изменено? - PullRequest
Новая
       129

Как вы можете убедиться, что электронное письмо было отправлено с правильного домена и что его содержимое не было изменено?

0 голосов
/ 28 мая 2020

Я изучаю свои заголовки электронной почты (отправленные из Gmail) и мне интересно, какие из них лучше всего подходят для проверки того, что электронное письмо было отправлено с правильного домена и что его содержимое не было изменено?

1 Ответ

0 голосов
/ 28 мая 2020

Я буду использовать пример сообщения, полученного мной от Stack Overflow, чтобы проиллюстрировать, что вы можете сделать для проверки сообщения вручную.

SPF не очень полезен после доставки поскольку это относительно небольшой (но важный) этап проверки источника сообщений, но хорошо знать, что в то время он был хорош, и заголовки говорят вам об этом. Части содержимого сообщения, связанные с доставкой, - это заголовок Return-path, добавленный получателем, а также последний заголовок Received, который показывает, откуда оно было получено: 

Return-Path: <bounces+3553988-07ba-marcus=example.com@em.stackoverflow.email>
Received: from o1.em.stackoverflow.email (o1.em.stackoverflow.email [167.89.81.234])
    (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
    (No client certificate requested)

Поиск этого em.stackoverflow.email domain в качестве записи TXT в DNS дает нам: 

# dig txt +short em.stackoverflow.email
u3553988.wl239.sendgrid.net.
"v=spf1 ip4:167.89.81.234 ip4:167.89.85.72 ip4:168.245.32.199 -all"

, и мы видим, что IP-адрес 167.89.81.234, который появляется в заголовке Received, явно указан в записи, поэтому SPF проверяется. Другие домены могут иметь более сложные потребности в проверке SPF, например, требовать дополнительных поисков DNS для механизмов include. Примечательно, что SPF даже не смотрит на адрес, используемый в заголовке From; он может быть полностью не связан с доменом обратного пути.

DKIM - это то место, где находится реальное действие. Вы можете использовать информацию в заголовке DKIM-signature, чтобы убедиться, что сообщение не было подделано. Например: 

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 
    d=stackoverflow.email; 
    h=from:subject:to:reply-to:mime-version:content-type; s=s1; 
    bh=IgKJJZNcUhfjH6LDr4XaWr3pBwq6wwxwyrGmf+k3DVo=; b=rR4J7VyvF3i0N
    20IX9bx0LGTKpSKj7XoHJurhBjcZLLTn/hXuZ8OMehfgMNFeXaMljlOz4tfoFwit
    aJ8UtK1oMVCPiv9200hpQViCh/5VsyYbs6k3YN6R3cFxMbrb7nflodXX+4Rp4xBu
    T+CloNFEDICtWJT4bVSrs/NRAUlJWY=

Посмотрите на заголовок From и убедитесь, что он соответствует домену, указанному в поле d подписи DKIM, что он и делает: 

From: Stack Exchange <do-not-reply@stackoverflow.email>

Подпись DKIM состоит из 2 частей: b - это подпись тела сообщения, а bh - подпись заголовков сообщения. Их взаимодействие довольно сложно. Чтобы сгенерировать подпись, сначала вы вычисляете подпись тела, затем вычисляете подпись заголовка , которая включает подпись тела вместе с канонизированными заголовками сообщений, перечисленными в элементе h , за исключением фактическое значение элемента bh, потому что это представляет проблему курицы и яйца. Подпись bh включает только перечисленные заголовки, потому что почтовые серверы могут добавлять другие заголовки, которые не должны быть включены или которые неизвестны на момент отправки, например Return-path и Received. Подпись переполнения стека необычна тем, что она не включает заголовок Date, поэтому дату сообщения можно изменить, не нарушая подпись DKIM.

Для проверки подписи вам понадобится ключ publi c он был подписан, что вы можете получить из DNS, используя поле s, которое предоставляет селектор, в данном случае s1: 

# dig txt +short s1._domainkey.stackoverflow.email
s1.domainkey.u3553988.wl239.sendgrid.net.
"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCyJRzkL/aRo1F1+ChY+Crt2TARqqo7tGATw3fMfzW8MXFWaoW1rSvZsq4k1EIf2iW7gO/QZjU1Td7h1aZpS63/CmpKymmqNbHnnbTxZGvZziKPcL/R2PVL0g88MFcpAuSjIsGysYTeow0mnXQ5W03z5mtWqm5nxNM40A/TIlOegwIDAQAB"

Одна проблема с этой подписью заключается в том, что она использует только 1024-битный ключ; gmail игнорирует подписи DKIM с менее чем 2048 битами, поэтому я не удивлюсь, если SO будет иметь проблемы с доставкой с gmail.

На самом деле проверка подписи DKIM - сложный процесс, особенно если он использует алгоритмы канонизации relaxed (что увеличивает вероятность того, что подписи переживут путешествие по электронной почте). Я написал a PHP DKIM-валидатор , который вы могли бы использовать для проверки ваших собственных сообщений.

Последний уровень - DMAR C, который связывает SPF, DKIM и From адрес заголовок вместе. Оглядываясь назад на Return-path, мы видим, что домен обратного пути является поддоменом домена, используемого в заголовке From. Это означает, что он подходит для «расслабленного», а не «строгого» выравнивания. Мы можем видеть запись DMAR C SO: 

# dig txt +short _dmarc.stackoverflow.email
"v=DMARC1;p=reject;sp=reject;pct=100;rua=mailto:dmarc-aggregates@stackoverflow.com;ruf=mailto:dmarc-forensics@stackoverflow.com;fo=1"

Это говорит нам, что SO хочет, чтобы получатели строго применяли проверки SPF и DKIM и отклоняли любые сообщения, которые не проверяются, и они настроили адреса для получения сводных c отчетов и отчетов о любых неудачных сообщениях.

Там гораздо больше подробностей, но на самом деле это не место для них. Обо всем этом есть хорошая статья здесь .

...