Fetchmail final delivery problem

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Fetchmail final delivery problem

Andrey Repin-2
Greetings, All!

I think I just broke my mail system. I'd like a quick help if possible.
I have a remote server that accepts the mail for domain right now.
The mail is retrieved from it by fetchmail and pushed to the local postfix
instance to be delivered to the user mailboxes using

mda "/usr/sbin/sendmail -iG -N never -f %F -- %T"

The problem is, only virtual recipients are delivered correctly.
An attempt to deliver mail for real users end in message being trashed with
"delivery loop detected".
The log says "bounced", but it is nowhere to be found. Not on postmaster,
neither on the sender's address.


--
With best regards,
Andrey Repin
Thursday, December 27, 2018 1:07:16

Sorry for my terrible english...

Reply | Threaded
Open this post in threaded view
|

Re: Fetchmail final delivery problem

Andrey Repin-2
Greetings, All!

> I think I just broke my mail system. I'd like a quick help if possible.
> I have a remote server that accepts the mail for domain right now.
> The mail is retrieved from it by fetchmail and pushed to the local postfix
> instance to be delivered to the user mailboxes using

> mda "/usr/sbin/sendmail -iG -N never -f %F -- %T"

> The problem is, only virtual recipients are delivered correctly.
> An attempt to deliver mail for real users end in message being trashed with
> "delivery loop detected".
> The log says "bounced", but it is nowhere to be found. Not on postmaster,
> neither on the sender's address.

Ok, I've managed to capture a bounce.
Here's headers of a message that was received (and bounced) by postfix.
Yes, the final destination is [hidden email], and the user actually
exists.

Return-Path: <[hidden email]>
Received: from mpmx.ht-systems.ru (localhost [127.0.0.1])
        by office.ccenter.msk.ru (Postfix) with ESMTP id AD35317BC894
        for <[hidden email]>; Thu, 27 Dec 2018 01:21:02 +0300 (MSK)
Delivered-To: [hidden email]
Received: from mp2.hts.ru (mp2.hts.ru [78.110.50.96])
        by hawk1.hts.ru (Postfix) with ESMTP id 90BD92701E7
        for <[hidden email]>; Thu, 27 Dec 2018 01:09:19 +0300 (MSK)
Received: from forward106j.mail.yandex.net (forward106j.mail.yandex.net [5.45.198.249])
        by mx1.hts.ru (Postfix) with ESMTP id 4A996261593
        for <[hidden email]>; Thu, 27 Dec 2018 01:09:19 +0300 (MSK)
Received: from mxback7g.mail.yandex.net (mxback7g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7
        by forward106j.mail.yandex.net (Yandex) with ESMTP id 0D10C216D0
        for <[hidden email]>; Thu, 27 Dec 2018 01:09:19 +0300 (MSK)
Received: from localhost (localhost [::1])
        by mxback7g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 19xFVSj28K-9IwShXtI;
        Thu, 27 Dec 2018 01:09:18 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1545862158;
        bh=8bL2YoABIr7Q/yVWk9+JxEh/vc9FPTUkpC1Owgw9nAQ=;
        h=From:To:Subject:Date:Message-Id;
        b=rsjzCFOo8dw5ekTXMeVUfJZT2HWFKyGiw1rYVtsRDaiA8oF7S0tznbcQLxS7LRieJ
         sJ1DaJiNZeGOU3bKOKiQoeWl0Q69lGaYDx4YxpPNdWXblZVEtAq4VPMD6UTkP4eX/p
         LGeuwWUN0ICSS9vj+klvfzSkXfxsA6Ff6MMnIrPc=
Authentication-Results: mxback7g.mail.yandex.net; dkim=pass header.i=@yandex.ru
Received: by iva1-16f33c6a446b.qloud-c.yandex.net with HTTP;
        Thu, 27 Dec 2018 01:09:18 +0300
From: Daemon ANR <[hidden email]>
To: =?utf-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCf0LXRgNC10LLQvtC30YfQuNC60L7Qsg==?= <[hidden email]
Subject: 1
MIME-Version: 1.0
X-Mailer: Yamail [ http://yandex.ru ] 5.0
Date: Thu, 27 Dec 2018 01:09:18 +0300
Message-Id: <[hidden email]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain



--
With best regards,
Andrey Repin
Thursday, December 27, 2018 1:28:52

Sorry for my terrible english...

Reply | Threaded
Open this post in threaded view
|

Re: Fetchmail final delivery problem

Wietse Venema
Andrey Repin:

> Greetings, All!
>
> > I think I just broke my mail system. I'd like a quick help if possible.
> > I have a remote server that accepts the mail for domain right now.
> > The mail is retrieved from it by fetchmail and pushed to the local postfix
> > instance to be delivered to the user mailboxes using
>
> > mda "/usr/sbin/sendmail -iG -N never -f %F -- %T"
>
> > The problem is, only virtual recipients are delivered correctly.
> > An attempt to deliver mail for real users end in message being trashed with
> > "delivery loop detected".
> > The log says "bounced", but it is nowhere to be found. Not on postmaster,
> > neither on the sender's address.
>
> Ok, I've managed to capture a bounce.
> Here's headers of a message that was received (and bounced) by postfix.
> Yes, the final destination is [hidden email], and the user actually
> exists.

Rule number one: email routing MUST NOT depend on the message
header content and it MUST NOT depend on the message body content.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Fetchmail final delivery problem

Andrey Repin-2
Greetings, Wietse Venema!

> Andrey Repin:
>> Greetings, All!
>>
>> > I think I just broke my mail system. I'd like a quick help if possible.
>> > I have a remote server that accepts the mail for domain right now.
>> > The mail is retrieved from it by fetchmail and pushed to the local postfix
>> > instance to be delivered to the user mailboxes using
>>
>> > mda "/usr/sbin/sendmail -iG -N never -f %F -- %T"
>>
>> > The problem is, only virtual recipients are delivered correctly.
>> > An attempt to deliver mail for real users end in message being trashed with
>> > "delivery loop detected".
>> > The log says "bounced", but it is nowhere to be found. Not on postmaster,
>> > neither on the sender's address.
>>
>> Ok, I've managed to capture a bounce.
>> Here's headers of a message that was received (and bounced) by postfix.
>> Yes, the final destination is [hidden email], and the user actually
>> exists.

> Rule number one: email routing MUST NOT depend on the message
> header content and it MUST NOT depend on the message body content.

It's neither. I have explicitly set final destination for each remote account.
If there any way to work around it, until the migration is done and the remote
server is decomissioned?


--
With best regards,
Andrey Repin
Thursday, December 27, 2018 4:02:58

Sorry for my terrible english...

Reply | Threaded
Open this post in threaded view
|

Re: Fetchmail final delivery problem

Matthias Andree
Am 27.12.18 um 02:05 schrieb Andrey Repin:

> Greetings, Wietse Venema!
>
>> Andrey Repin:
>>> Greetings, All!
>>>
>>>> I think I just broke my mail system. I'd like a quick help if possible.
>>>> I have a remote server that accepts the mail for domain right now.
>>>> The mail is retrieved from it by fetchmail and pushed to the local postfix
>>>> instance to be delivered to the user mailboxes using
>>>
>>>> mda "/usr/sbin/sendmail -iG -N never -f %F -- %T"
>>>
>>>> The problem is, only virtual recipients are delivered correctly.
>>>> An attempt to deliver mail for real users end in message being trashed with
>>>> "delivery loop detected".
>>>> The log says "bounced", but it is nowhere to be found. Not on postmaster,
>>>> neither on the sender's address.
>>>
>>> Ok, I've managed to capture a bounce.
>>> Here's headers of a message that was received (and bounced) by postfix.
>>> Yes, the final destination is [hidden email], and the user actually
>>> exists.
>
>> Rule number one: email routing MUST NOT depend on the message
>> header content and it MUST NOT depend on the message body content.
>
> It's neither. I have explicitly set final destination for each remote account.
> If there any way to work around it, until the migration is done and the remote
> server is decomissioned?

Without fetchmail configuration details and logs, it's too hard to debug
remotely.

As Wietse stated, %T might be dangerous, if it's a single-user mailbox,
you might as well just specify the user's name instead.  Else you _must_
make sure that fetchmail can properly derive envelope recipient headers
(assuming that your mailbox stores them in some form), and that in turn
assumes that your fetchmail configuration makes for a constant
recipient...

In which case you need to make sure that the messages you inject from
fetchmail does not end up in the mailbox you are fetching from - which
is what might be happening.

For the fetchmail end, see
<http://www.fetchmail.info/fetchmail-FAQ.html#G3> (again, remove passwords).
Reply | Threaded
Open this post in threaded view
|

Re: Fetchmail final delivery problem

Andrey Repin-2
Greetings, Matthias Andree!

> Am 27.12.18 um 02:05 schrieb Andrey Repin:
>> Greetings, Wietse Venema!
>>
>>> Andrey Repin:
>>>> Greetings, All!
>>>>
>>>>> I think I just broke my mail system. I'd like a quick help if possible.
>>>>> I have a remote server that accepts the mail for domain right now.
>>>>> The mail is retrieved from it by fetchmail and pushed to the local postfix
>>>>> instance to be delivered to the user mailboxes using
>>>>
>>>>> mda "/usr/sbin/sendmail -iG -N never -f %F -- %T"
>>>>
>>>>> The problem is, only virtual recipients are delivered correctly.
>>>>> An attempt to deliver mail for real users end in message being trashed with
>>>>> "delivery loop detected".
>>>>> The log says "bounced", but it is nowhere to be found. Not on postmaster,
>>>>> neither on the sender's address.
>>>>
>>>> Ok, I've managed to capture a bounce.
>>>> Here's headers of a message that was received (and bounced) by postfix.
>>>> Yes, the final destination is [hidden email], and the user actually
>>>> exists.
>>
>>> Rule number one: email routing MUST NOT depend on the message
>>> header content and it MUST NOT depend on the message body content.
>>
>> It's neither. I have explicitly set final destination for each remote account.
>> If there any way to work around it, until the migration is done and the remote
>> server is decomissioned?

> Without fetchmail configuration details and logs, it's too hard to debug
> remotely.

> As Wietse stated, %T might be dangerous, if it's a single-user mailbox,
> you might as well just specify the user's name instead.  Else you _must_
> make sure that fetchmail can properly derive envelope recipient headers
> (assuming that your mailbox stores them in some form), and that in turn
> assumes that your fetchmail configuration makes for a constant
> recipient...

fetchmail do not derive anything, the local recipient is set explicitly, and
yes, it was a single user, with no domain part.

Literal rejection text was

Dec 26 23:09:04 mxs postfix/local[1944]: 8540017BC8F0: to=<[hidden email]>, orig_to=<alexandr>, relay=local, delay=0.4, delays=0.3/0/0/0.1, dsn=5.4.6, status=bounced (mail forwarding loop for [hidden email])

I worked around it by specifying a local domain for recipient addresses.

poll pop3.ht-systems.ru
        protocol POP3
        uidl
        auth password
        user [hidden email]
        password "..."
        to [hidden email]

> In which case you need to make sure that the messages you inject from
> fetchmail does not end up in the mailbox you are fetching from - which
> is what might be happening.

It's two different systems. I wasn't expecting such behavior.

> For the fetchmail end, see
> <http://www.fetchmail.info/fetchmail-FAQ.html#G3> (again, remove passwords).


--
With best regards,
Andrey Repin
Thursday, December 27, 2018 12:36:26

Sorry for my terrible english...