Re: [Comm] fetchmail and multidrop mailbox

[Aleksandr Fetininsky <sashurik@telecont.ru>]

On Mon, Sep 22, 2003 at 14:54:23 +0300, Alexandr R. Ogurtzoff wrote:
> Здравсвуйте уважаемые!
> Есть у меня один такой себе неприятный момент при заборе почты с общего для 
> домена ящика. в рассылках подставляется адрес рассылки и fetchmail забирает 
> почту уже для postmaster. Умные люди говорят что провайдер по видимому не 
> прописывает поле envelope to. Верно ли это и могу ли я от него требовать 
> наличие такого поля. впринципе всё бы ничего, но есть партнёры, которые для 
> рассылок используют что то там мелкомягкое и отправляют почту на свой же 
> адрес а потом оттуда уже  идёт рассылка. Как и чем они это делают ума не 
> приложу, то ли общие адрессные книги то ли ещё что то... Так вся такая почта 
> у меня как у почт мастера и накапливается. Как победить, мозгу не приложу... 
> Procmail - наверное не совсем удобно, им хорошо личную почту сортировать а не 
> для всего домена, действительно провайдера попинать? Что подскажете вот часть 
> лога общения с сервером провайдера командочки fetchmail -vv -D mercuri.mk.ua 
				<skipped> 
> fetchmail: analyzing Received line:
> Received: by lrn.ru (Postfix, from userid 128)
>         id 592414820A; Mon, 22 Sep 2003 14:58:56 +0400 (MSD)
> fetchmail: line rejected, lrn.ru is not an alias of the mailserver
> fetchmail: analyzing Received line:
> Received: from lrn.ru (localhost.localdomain [127.0.0.1])
>         by lrn.ru (Postfix) with ESMTP
>         id 2C2074813E; Mon, 22 Sep 2003 14:58:22 +0400 (MSD)
> fetchmail: line rejected, lrn.ru is not an alias of the mailserver
> fetchmail: analyzing Received line:
> Received: by lrn.ru (Postfix, from userid 128)
>         id A065F4808D; Mon, 22 Sep 2003 14:58:16 +0400 (MSD)
> fetchmail: line rejected, lrn.ru is not an alias of the mailserver
> fetchmail: analyzing Received line:
> Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235])
>         by lrn.ru (Postfix) with ESMTP id 7AFB24808B
>         for <community@lrn.ru>; Mon, 22 Sep 2003 14:58:16 +0400 (MSD)
> fetchmail: line rejected, lrn.ru is not an alias of the mailserver
> fetchmail: analyzing Received line:
> Received: from tu.edu.te.ua (maingate.tu.edu.te.ua [217.196.167.2])
>         by master.altlinux.ru (Postfix) with ESMTP id CA021E31DA
>         for <community@altlinux.ru>; Mon, 22 Sep 2003 14:58:08 +0400 (MSD)
> fetchmail: line rejected, master.altlinux.ru is not an alias of the mailserver
> fetchmail: analyzing Received line:
> Received: from cs-704-02 [192.168.119.12] by tu.edu.te.ua with ESMTP
>         (SMTPD32-7.07) id A5B9530358; Mon, 22 Sep 2003 13:58:01 +0300
						<skipped> 
> fetchmail: no local matches, forwarding to postmaster
					<skipped>
>  Это вот ~/.fetchmailrc
> 
> set postmaster "postmaster"
> set bouncemail
> set no spambounce
> set properties ""
> poll pop3.mk.farlep.net with proto POP3
>     localdomains mercuri.mk.ua
>     user 'iscander' there with password 'Мойпароль'  is *  here options / 
> fetchall 
> 
> Может чего здесь дописать надо?

Hint: Любите FAQ'и - источник знаний!

Поxоже в /usr/share/doc/fetchmail-6.2.2/FAQ описана эта проблема:

M1. I've declared local names, but all my multidrop mail is going
to root anyway.

Somehow  your  fetchmail  is  never  recognizing  the hostname
part of recipient  names  it  parses  out  of To/Cc/envelope-header
lines as matching  the  name  of  the  mailserver  machine.  To
check this, run fetchmail  in foreground with -v -v on. You will
probably see a lot of messages  with  the  format ``line rejected,
%s is not an alias of the mailserver'' or ``no address matches;
forwarding to %s.''
 These  errors  usually indicate some kind of DNS configuration
problem either on the server or your client	machine.
 The easiest workaround is to add a `via' option (if necessary)
and add enough  aka  declarations  to cover all of your mailserver's
aliases, then  say  `no  dns'. This will take DNS out of the picture
(though it means  mail  may  be uncollected  if  it's  sent	to  an
alias of the mailserver that you don't have listed).
 It would be better to fix your DNS, however. DNS problems can hurt
you in lots of ways, for example by making your machines
intermittently or permanently unreachable to the rest of the
net.
 Occasionally these errors indicate the sort of header-parsing
problem described in M7.
				 	^^^^
				и здесь
> -- 
> 
> С наилучшими пожеланиями
> Александр Огурцов 

--
Удачи

  Александр