Hello, Victor Sudakov! On Tue, Jun 28, 2011 at 09:17:33AM +0700 sudakov@sibptus.tomsk.ru wrote about "[uanog] борцуны со спамом":

Совсем народ с ума сошел, отвергает почту по return-path. Это при живой SPF записи!

Failed to deliver to 'XXXXXXXXXXX@att.net' SMTP module(domain att.net) reports: return-path address rejected by aln-mailrelay.att.net: 521 DNSRBL: Blocked for abuse. See http://att.net/blocks

А что я могу поделать со спуфингом моего адреса? Да ничего, кроме настройки SPF.

А вы раньше их при помощи sender-verify не могли случайно замучать? -- Lystopad Olexandr

Hello, Victor Sudakov! On Tue, Jun 28, 2011 at 01:49:54PM +0700 sudakov@sibptus.tomsk.ru wrote about "Re: [uanog] борцуны со спамом":

Lystopad Aleksandr wrote:

...

...

Совсем народ с ума сошел, отвергает почту по return-path. Это при живой SPF записи!

Failed to deliver to 'XXXXXXXXXXX@att.net' SMTP module(domain att.net) reports: return-path address rejected by aln-mailrelay.att.net: 521 DNSRBL: Blocked for abuse. See http://att.net/blocks

А что я могу поделать со спуфингом моего адреса? Да ничего, кроме настройки SPF.

А вы раньше их при помощи sender-verify не могли случайно замучать?

У меня нет sender-verify. В принципе мог замучать ответами listserv-а или автоответчиком abuse@.

Думаю на это атт обращает внимание: Testresult for 212.73.124.8: This IP IS CURRENTLY LISTED in our Database. ... This kind of abuse is known as BACKSCATTER (Misdirected Bounces or Misdirected Autoresponders or Sender Callouts). http://www.backscatterer.org/index.php?target=test -- Lystopad Olexandr

Hello, Victor Sudakov!

Сразу попутно вопрос. Есть несколько абонентов, для которых мы держим backup MX. Настроен recipient callout. Но у абонентов видимо есть свои спаморезы, и иногда они отвечают нашему backup MX-у 5xx после DATA. Соответственно он шлёт баунс (возможно несуществующему) отправителю. Отсюда и backscatter скорее всего.

Какая в этом случае правильная практика отношений с абонентом?

Думаю, что в этом случае и абонент и провайдер заинтересованы в том, чтобы не было МХ-а. Пусть лучше письма поболтаются в очередях у отправителей, чем придут на ваш МХ и отобъются, да и вы еще себя подставите в bl. Абонент о таких случаях сможет узнать только если обратится к провайдеру, ну или интуитивно начнет изучать свои логи (смотря как у вас сделан recipient callout). Вообще, абоненту МХ-ы больше опасность, чем польза. Мало ли какие у провайдера acl, мало ли какой сбой случился и на все письма провайдер выдал 5xx ошибку? Абонент может не узнать какое важное письмо он потерял и когда. -- Lystopad Olexandr

On Fri, Jul 01, 2011 at 09:19:25AM +0700, Victor Sudakov writes: VS> Сразу попутно вопрос. Есть несколько абонентов, для которых мы держим VS> backup MX. Настроен recipient callout. Но у абонентов видимо есть свои VS> спаморезы, и иногда они отвечают нашему backup MX-у 5xx после DATA. VS> Соответственно он шлёт баунс (возможно несуществующему) отправителю. VS> Отсюда и backscatter скорее всего. VS> Какая в этом случае правильная практика отношений с абонентом? Я на почтовике, который работает как secondary MX, отключил отправку bounces о недоставке. Отсутствие баунса давно не является гарантией того, что письмо благополучно дошло до адресата и не было съедено спамфильтром. Если же у клиента возникает вопрос "Мне писали, куда потерялось это письмо?", ответ он может найти в своём собственном логе. Я не считал, но по моим ощущениям 97% боунсов - на спам, 2% - на письма, которые были ошибочно приняты за спам (и вполне могли быть удалены молча), и ещё 1% - из-за глюков в настройке MTA. Информативные баунсы вроде "Вася здесь больше не работает, пишите ему на адрес vasya@gmail.com" обычно шлются не в smtp-диалоге, а формируются отдельным письмом автоответчика. -- Паша.