LINUX.ORG.RU
Форум — Admin  

борьба антиспам систем

 


0

1

Есть вполне обычные почтовая система№1 и почтовая система№2.
Система№1 использует в качестве одной из антиспамерских мер - проверку существования адресата через реверсный коннект на отправителя.
Система№2 использует «серые списки» aka greylisting с таймаутом.
Соответственно при поступлении письма от №2 к №1 - блочится из за таймаута greylisting.
Система№2 - чужая.

ВОПРОС:
Кто прав?
Кто виноват?

★★★★★

Последнее исправление: Atlant (всего исправлений: 2)

Оба виноваты. По стандартам повторные отправки предполагаются, а такие обратные нет, вроде. Больше первый виноват, особенно если он отвергает не с тем кодом, что повтора от второго не будет. Второй дополнительно виноват, если на прямом соединении к первому тоже таймаут образуется, а повторной отправки от второго нет.

boowai ★★★★
()
Ответ на: комментарий от boowai

особенно если он отвергает не с тем кодом, что повтора от второго не будет

оба отвечают кодами «временный сбой»
------
№1 отвечает на исходное письмо «450 4.1.7 <*****@********.ru>: Sender address rejected: unverified address:„host
mail.******.ru[*.*.*.*] said: 451 4.7.1 Greylisting in action, please come back later (in reply to RCPT TO command)“

№2 отвечает на реверсное письмо „451 4.7.1 Greylisting in action, please come back later“.
------
По сути, идет торможение - пока не пройдет таймаут.

Atlant ★★★★★
() автор топика

Кто прав?
Кто виноват?

Издержки борьбы со спамом. Укладывается в сроки доставки сообщения (https://tools.ietf.org/html/rfc5321#section-4.5.4)?

Вообще лучше бы грейлистринг включать во-первых избирательно, во-вторых в DATA.

AS ★★★★★
()
Ответ на: комментарий от Atlant

Но разными кодами отвечают. 4## коды из категории временных проблем, но в стандарте нет строгого обязательства повторной попытки, SHOULD, вроде.

450 4.1.7 первого довольно строго отвергает (дальше цитата ответа второго, так что она не считаетя). Второй, как клиент может, и не повторить попытку. Проблема в этом, что повторных попыток от второго нет? Попробуй настроить другие коды на первом.

boowai ★★★★
()
Последнее исправление: boowai (всего исправлений: 2)
Ответ на: комментарий от boowai

но в стандарте нет строгого обязательства повторной попытки

while mail that cannot be transmitted immediately MUST be ueued and periodically retried by the sender.

Это прямо по той ссылке, что я привёл: «4.5.4.1. Sending Strategy».

AS ★★★★★
()
Ответ на: комментарий от AS

https://tools.ietf.org/html/rfc5321#section-4.2.1

4yz
… in this category might have a different time value, but the SMTP client SHOULD try again.

По твоей логике MUST перекроет и

5yz … SMTP client SHOULD NOT repeat

boowai ★★★★
()
Последнее исправление: boowai (всего исправлений: 1)

ВОПРОС:
Кто прав?
Кто виноват?

Это что, адвокатский форум? Тебе нужно чтобы работало, ну так и делай, чтобы работало.

anonymous
()
Ответ на: комментарий от boowai

По твоей логике MUST перекроет и

С 5xx вопрос интересный, но после 4xx - повторные попытки обязательны. Вот на количество и интервал жёсткого регламента нет, наверное формально можно и одну попытку. :-)

AS ★★★★★
()
Ответ на: комментарий от anonymous

Тебе нужно чтобы работало, ну так и делай, чтобы работало.

Может не очень нужно? Мне вот нужно, но не на столько, чтобы от всех подряд. На той стороне тоже должны голову иметь до какой-то степени.

AS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin