AC> Это проверка существования отправителя. Т.е. того, кому, в случае AC> приема письма и ошибки при доставке, следует слать bounce. Делается в AC> самом простом случае проверкой домена, а в менее тупом - таки проверкой AC> полного адреса, т.е. походом к его MX'у от имени <> (баунс будет слаться AC> именно от него, ага) и выслушиванием ответа на RCPT TO: [EMAIL PROTECTED] AC> Диалог в сем процессе нам и был продемонстрирован.
AC> Т.е. в переводе на русский: грейлистер шлет письмо. К нему с того конца AC> приходит verify callout (должен заметить, что callout может вполне AC> валидно приходить и не с того же IP). Он этот callout своим грейлистом AC> посылает. Принимающая оригинальное письмо сторона, видя ошибку verify, AC> выдает свою ошибку - "verify failed, идите нафиг". и если она так делает, то это значит настраивал ее ИДИОТ! потому что грейлист отдает ошибку "временные проблемы при приеме" а никак не "такой юзер отсутствует" AC> Другое дело, что получив 4xx при верификации, стоило бы отдать 4xx и в AC> ответ, но это уже должен быть умный sender verify... Но в любом случае AC> при этом грейлистер сам же свое же собственное письмо и задерживает. -- . ''`. Dmitry E. Oboukhov : :’ : [EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
signature.asc
Description: Digital signature
