[Карта]                      <[Карта]                [Начало]                [Sendmail-ссылки]                [Синтаксис]                [Типовые задачки]                  [Задачки по маршрутизации]                  [Задачки по маcкарадингу]                  [SendmailACL]                  [Spamooborona]                  [VadeRetro]                  [Regex]                  [Тонкости]                  [Недок.особен.]                  [Несущ.юзеры]                  [Прячемся!]                  [RFC1893.Цитаты]                  [ТП.Эмоции]                  [Антиспам&Разум]                  [Экзерсисы]                 


Sendmail и несуществующие пользователи.

  • 1. Теория
  • 2. Практика
    1. Теория.
    Если ваша почтовая система - основной mx (т.е. с наименьшим весом), и почтовые пользователи являются системными, и к sendmail не привязан кривой фильтр, то проблемы с несуществующими пользователями не должно быть по определению.
    Прошу прощения у тех, кого я ввела в заблуждение утверждением, что "Отлуп несущ. пользователю зашит в самом файле sendmail, и sendmail.cf за это не отвечает". А периодически всплывающий до сих пор от владельцев связок sendmail+cyrus & sendmail+kavkeeper на форумах вопрос "Как заставить sendmail не принимать почту для несуществующих пользователей" лишь прибавлял уверенности в том, что sendmail'у нужно объяснять, кто свой, а кто чужой. Спасибо to Spirit (www.linux.org.ru) за то, что сподвигнул меня разобраться в этом вопросе. Благодаря заботливо :) сохраненным мною логам за 2002г. выяснилось, что это заблуждение возникло у меня от общения с KAV, kavkeeper которого не проверяет наличие пользователя в системе, о чем имелась запись в FAQ. Поэтому письмо сначала принимается системой, а потом формируется отлуп от MAILER-DAEMON и посылается отправителю письма:

    Feb 2 04:10:09 mail sendmail[1476]: EAA01476: from=<noch857@omnisp.ru>, size=11975, class=0, pri=41975, nrcpts=1, msgid=<081101c2caa2$bc171fe0$a33f43c2@kwinstar>, proto=ESMTP, relay=jack.omnisp.ru [194.67.63.1]
    Feb 2 04:10:12 mail sendmail[1488]: EAA01488: to=ise@anrb.ru.KAV, delay=00:00:00, mailer=local, stat=User unknown
    Feb 2 04:10:12 mail sendmail[1488]: EAA01488: from=noch857@omnisp.ru, size=12184, class=0, pri=42184, nrcpts=1, msgid=<081101c2caa2$bc171fe0$a33f43c2@kwinstar>, relay=root@localhost
    Feb 2 04:10:12 mail sendmail[1488]: EAA01488: EAB01488: DSN: User unknown
    Feb 2 04:10:13 mail sendmail[1500]: EAA01500: from=MAILER-DAEMON, size=13543, class=0, pri=43543, nrcpts=1, msgid=<200302012310.EAB01488@mail.anrb.ru>, relay=root@localhost
    Feb 2 04:10:13 mail sendmail[1478]: EAA01476: to=<ise@anrb.ru>, delay=00:00:05, xdelay=00:00:04, mailer=kavkeeper, relay=anrb.ru.KAV, stat=Sent
    Feb 2 04:10:13 mail sendmail[1488]: EAB01488: to=noch857@omnisp.ru, delay=00:00:01, xdelay=00:00:01, mailer=kavkeeper, relay=omnisp.ru.KAV, stat=Sent
    Feb 2 04:10:20 mail sendmail[1502]: EAA01500: to=noch857@omnisp.ru.KAV, ctladdr=MAILER-DAEMON (0/0), delay=00:00:06, xdelay=00:00:06, mailer=esmtp, relay=relay1.omnisp.ru. [194.67.63.1], stat=Sent (2.0.0 h11N6mO17642 Message accepted for delivery)

    На самом деле sendmail проверяет наличие пользователя в системе через флаг w (см. в sendmail.cf строку Mlocal, P=/bin/mail, F=lsDFMmnPw, S=10, R=20, A=mail -d $u):
    "...Нижеописанные флаги могут быть установлены в описании почтовой программы...
    w                  Пользователь должен иметь действительный бюджет на этой машине, т.е., getpwnam
                       должен быть успешным. Если это не так, почта не будет доставлена. Это требуется для
                      работы ".forward".
    ..." (Installtaion and operation guide. 5. Полное Описание Файла Конфигурации)

    Spirit: "... флаг "w" - он для sendmail-а, а не для MDA, т.е. если sendmail определил, что дальнейшая доставка должна вестись таким-то mailer-ом, и в описании этого mailer-а стоит флаг "w", то существование получателя будет определяться самим sendmail-ом. И если он увидит, что такого пользователя несуществует, естественно он не будет принимать письмо, т.е. до приема письма и передачи его delivery agent-у даже не дойдет (ибо смысл ?)..."
    Справедливости ради нужно отметить , что в нынешнем KAV-MILTER проблемы с несуществующими пользователями нет.

    Отлуп несущ. пользователю в стандартной конфигурации происходит после набора правил check_rcpt, но перед тем как послать ответ на команду RCPT TO:
    op.me: "...
    ${nrcpts}
    The number of validated recipients for a single message.
    Note: since recipient validation happens after check_rcpt has been called, the value in this ruleset
    is one less than what might be expected..."


    2. Практика.
    Итак, проблема с несуществующими пользователями появляется в следующих случаях:
    1. sendmail + KAV-старых-версий + системные пользователи.
    Решение. Проверяем получателя в Local_check_rcpt

    2. sendmail + KAV-старых-версий + несистемные пользователи.
    Решение. Проверяем получателя в access
    To:user1@domain.ru                  OK
    To:user2@domain.ru                  OK
    To:user3@domain.ru                  OK
    To:user4@domain.ru                  OK
    To:domain.ru                 ERROR:5.1.1:550 Unknown user

    3. sendmail +cyrus
    Решения и консультации от Andrzej Adam Filip.
    Он постоянно напоминает на sendmail-конфе о своем проекте *RTCyrus: Sendmail and Cyrus-IMAP integration* и открыт для общения.
    I would like to post periodic information/reminder about RTCyrus-3 recipes for Sendmail and Cyrus IMAP integration
    [1]
    [2]
    [3]
    [4]
    [5]
    ckuser_cyrus.m4 - SENDMAIL+CYRUS address validation feature. [Источник]
    Gleb Smirnoff [8]
    [9]
    [9].1
    Unknown users not being rejected at RCPT TO: Options
    Если эти решения не подходят, то через access.
    [10].


    4. sendmail + second-mx
    Если ваша почтовая система - второй mx и тд, то, естественно, что почтовые пользователи не являются системными. И именно вторичные mx-ы больше всего страдают от перебора пользователей спамерами: ведь отправив по простоте душевной письмо для несущ. получателя на основной mx, они неизменно получают отлуп от основного mx-а, который пытаются вернуть отправителю, которого чаще всего не существует, а стало быть извещение об этом свалится в конечном итоге постмастеру второго mx-a.
    Решение. access + в зависимости от версии sendmail очень полезная FEATURE, позволяющая назначать ключ RELAY электронному адресу (по умолчанию этот ключ м.б. назначен только домену или сетке/адресу)

    Если в любом из описанных выше 4 случаев, вы решите использовать access, то можно использовать проверку на количество неопознанных объектов среди получателей с последующим блокированием.

    22.04.2008. У этой проблемы есть решение через milter.
    Milter-ahead (платный): "Allows a gateway mail server to call-ahead to another MX server or internal mail store before accepting mail for recipients of a message. Think of it as a lazy man's LDAP. It could also be used by fallback MX servers to verify recipients with the primary MX."
    20.02.2009. There is milter-ahead that checks first if destination side will accept mail for the target e-mail and only then accepts message body from the sender. It keeps cache and does not hit destination side too often. Works just fine for me.
    Кроме того к этой проблеме можно подойти и с другой стороны: проверить адрес отправителя. Минусы - здесь. Это, конечно, хуже, чем проверка существования получателя (если получатель на нашей удаленной системе), но, по крайне мере, в случае отсутствия такого юзера на конечной системе промежуточный mx не будет мучаться с доставкой отлупов несуществующему отправителю, а спокойно отдаст отлуп тому, кто и должен его получить.
    smf-sav - Sendmail Sender Address Validator

    Что же делать, если ничто из вышеперечисленного вас не устраивает?
    1. Использовать опцию LUSER_RELAY', позволяющую отправлять почту для несуществующих пользователей в указанном вами направлении. Этот способ нерационален в части создания лишнего трафика и лишней нагрузки, но в безвыходной ситуации - это единственное, что можно сделать с такой почтой.
    2. Поднастроить опцию confDOUBLE_BOUNCE_ADDRESS, чтобы двойные отказы не забивали почту постмастера.
    3. И не помешает поднастроить Timeout.queue*, чтобы очередь не забивалась.
    Хотя этот тред, как оказалось, не имел никакого отношения к проблеме с несущ-ми адресами, думаю, что уменьшение времени нахождения писем в очереди частично спасло бы автора, пока он разбирался с основной проблемой.








    Переписано 30 ноября 2007г.
    26 февраля 2009г.