Postfix gedraagt zich anders na een switch van ISP

[Verwijderd]

Dames en Heren,

Ik doe in mijn vrije tijd het ICT beheer van een regionaal streekmuseum en nu kan ik echt wel wat advies gebruiken. Laat ik het even zo goed mogelijk uit de doeken doen...

We gebruiken sinds een half jaar naar volle tevredenheid het Nederlandse Zarafa voor email. De ISP was tot voor kort KPN en de email van buiten kwam in de eerste plaats in vijf POP mailboxen aldaar. Om de mail op te halen heb ik destijds getmail gebruikt die de mail vervolgens aan Postfix aanbied die vervolgens de mail aan Zarafa aanbied. Uitgaande mail gaat van Zarafa naar postfix en van daar naar de smtp server van KPN.

So far so good. Iedereen blij. Nu wil dit museum meer dan vijf email boxen en aangezien dat bij KPN ruim meer zou gaan kosten dan een kompleet abonnement bij, laten we zeggen Protagonist, hebben we besloten de email en web hosting te verhuizen. Afgelopen week was het zover.

Webhosting ok. Geen enkel probleem.

Email ontvangen... Hmm minder...

De 10 email pop boxen worden keurig door getmail uitgelezen, de mail wordt aangeboden aan postfix en daar gaat “het” ineens anders. Voor de switch gebruikte postfix het lmtp protocol om email aan de zarafa-dagent (een lmtp client) aan te bieden.

Een en ander is duidelijk in /etc/mail.log te zien. Onderstaand een stukje waarbij de postfix pickup, cleanup, qmgr, LMTP en qmgr duidelijk te zien zijn.

code:

Sep 24 19:24:52 bunto804 postfix/pickup[5944]: 224B6326FB: uid=1001 from=<vmail>
Sep 24 19:24:52 bunto804 postfix/cleanup[5946]: 224B6326FB: message-id=<[e-mail]>
Sep 24 19:24:52 bunto804 postfix/qmgr[5945]: 224B6326FB: from=<[e-mail]>, size=9094, nrcpt=1 (queue active)
Sep 24 19:24:52 bunto804 postfix/lmtp[5949]: 224B6326FB: to=<[e-mail]>, relay=127.0.0.1[127.0.0.1]:2003, delay=84, delays=84/0.12/0.1/0.24, dsn=2.1.5, status=sent (250 2.1.5 [e-mail] Ok)
Sep 24 19:24:52 bunto804 postfix/qmgr[5945]: 224B6326FB: removed

NU wil postfix om redenen die ik niet kan achterhalen een local delivery doen en komt dan tot de conclusie dat er sprake is van een bounce situatie. Onderstaand een stukje van /etc/mail.log

code:

Sep 24 19:28:29 bunto804 postfix/pickup[6311]: EEC74326B1: uid=1001 from=<vmail>
Sep 24 19:28:29 bunto804 postfix/cleanup[6313]: EEC74326B1: message-id=<[e-mail]>
Sep 24 19:28:30 bunto804 postfix/qmgr[6312]: EEC74326B1: from=<[e-mail]>, size=2830, nrcpt=1 (queue active)
Sep 24 19:28:30 bunto804 postfix/local[6315]: EEC74326B1: to=<[e-mail]>, relay=local, delay=31, delays=31/0.01/0/0.01, dsn=5.4.6, status=bounced (mail forwarding loop for [e-mail])
Sep 24 19:28:30 bunto804 postfix/cleanup[6313]: 07F44326B2: message-id=<[e-mail]>
Sep 24 19:28:30 bunto804 postfix/qmgr[6312]: 07F44326B2: from=<>, size=4623, nrcpt=1 (queue active)
Sep 24 19:28:30 bunto804 postfix/bounce[6316]: EEC74326B1: sender non-delivery notification: 07F44326B2
Sep 24 19:28:30 bunto804 postfix/qmgr[6312]: EEC74326B1: removed

Ik kan er maar niet achter komen WAAROM postfix in de nieuwe situatie kiest voor local delivery in plaats van lmtp delivery zoals voorheen.

Any idea’s?

PS: het gebruikte systeem is Ubuntu 8.04, getmail, Postfix en Zarafa.

[Wolfboy]

Mijn gok is dat "liemersmuseum.nl" niet in je local domains staat en dat postfix het daarom blokkeert.

Voeg dus eens iets als dit toe aan main.cf

mydomain = liemersmuseum.nl

[Verwijderd]

Wolfboy schreef op vrijdag 24 september 2010 @ 21:50:
Mijn gok is dat "liemersmuseum.nl" niet in je local domains staat en dat postfix het daarom blokkeert.

Vergeet niet dat dit een werkende situatie was. Het bovenstaande was al in orde... Kijk maar

code:

#
# /etc/postfix/main.cf
#
# 20100509 Initial version for liemersmuseum.nl
#
# Minimal banner as required by the SMTP protocol.
#
smtpd_banner = $myhostname ESMTP

#
# The local biff notification service is not usefull here.
#
biff = no

#
# Appending the domain to locally submitted mail is not needed here.
#
append_dot_mydomain = no

#
# Only receive mail form here.
#
inet_interfaces = loopback-only

#
# The internet hostname of this mail system.
#
myhostname = bunto804.localdomain

#
# The domain name that mail appears to come form and delivered to.
#
myorigin = liemersmuseum.nl

#
# List of domains for LMTP delivery.
#
mydestination = liemersmuseum.nl, bunto804.localdomain, localhost.localdomain, localhost

#
# The postfix SMPT service wants to check valid recipients.
#
local_recipient_maps = hash:/etc/aliases

#
# alias_maps and database are used for local delivery.
#
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

#
# The next hop destination of non-local mail.
#
relayhost = smtp.kpn-officedsl.nl

#relayhost = smtp.liemersmuseum.nl

#
# Message delivery for the outbound delivery agent.
#
mailbox_command = /usr/bin/zarafa-dagent "$USER"

#
# Message delivery for the local delivery agent.
#
mailbox_transport = lmtp:127.0.0.1:2003

#
# 20100606 Increased message size
#
message_size_limit = 20480000

#
# EOF
#

[Wolfboy]

De config lijkt goed dus ik gok dat het door een hosts file komt.

Dit probleem krijg je als postfix mail krijgt voor een domein waar het geen mail voor mag/kan ontvangen.

Dit kan gebeuren als:

• Je een nieuw domein hebt maar het nog niet toegevoegd hebt aan je postfix config (lijkt hier niet het geval dus)
• Het domein heeft een MX record dat naar localhost verwijst. In dat geval moet er dus ergens een dns record of regel in je hosts file staan die het domein naar 127.0.0.1 richt

[burne]

Wolfboy schreef op zaterdag 25 september 2010 @ 01:22:
Dit probleem krijg je als postfix mail krijgt voor een domein waar het geen mail voor mag/kan ontvangen.

Om precies te zijn: heb je niet iets met KPN's hosted Exchange-dienst in je /etc/hosts of /etc/postfix/transport staan wat je eigenlijk moet vervangen door spambuster.protagonist.nl?

Sowieso moet je relayhost in /etc/postfix/main.cf nog even fixxen

[ Voor 8% gewijzigd door burne op 25-09-2010 01:31 ]

[Verwijderd]

burne schreef op zaterdag 25 september 2010 @ 01:30:
[...]
Sowieso moet je relayhost in /etc/postfix/main.cf nog even fixxen

Mee eens natuurlijk. Het werkt nog wel omdat het abonnement bij de KPN nog niet afgelopen is. Maar ik ga het toch alvast maar aanpassen.

Overigens staan er in "mijn" /etc/hosts geen vreemde dingen.

Ik ben nu regel voor regel aan het vergelijken hoe de emails van een goede en een niet goede situatie er uit zien. I'll be back...

[Verwijderd]

Wolfboy schreef op zaterdag 25 september 2010 @ 01:22:
Het domein heeft een MX record dat naar localhost verwijst. In dat geval moet er dus ergens een dns record of regel in je hosts file staan die het domein naar 127.0.0.1 richt

In /etc/hosts staan geen "vreemde" dingen. Ik ga verder...

[Verwijderd]

Random guess, kijk hier eens naar:
http://www.kolab.org/pipe...2005-November/003756.html

Komt er zo'n header voor in de mails die je bij de ISP ophaalt? Zo ja, dan zou dat de reden kunnen zijn waarom Postfix zich opeens anders is gaan gedragen.

Twee oplossingen die als eerste in me op komen:
- pas je fetchmail-config aan zoals gespecificeerd;
- haal de binnenkomende mail eerst door een eenvoudig (evt. zelfgeschreven) filter om die ene header line weg te greppen.

[Verwijderd]

Verwijderd schreef op zaterdag 25 september 2010 @ 12:13:
Komt er zo'n header voor in de mails die je bij de ISP ophaalt? Zo ja, dan zou dat de reden kunnen zijn waarom Postfix zich opeens anders is gaan gedragen.

BINGO! Dat is'em helemaal. Kijk maar eens naar de onderstaande (bovenste gedeeltes van) een email die goed gaat (code 1) en een die fout gaat (code 2). Even later kwam ik ook de onderstaande tekst (code 3) in de man page van postfix tegen. Ben zojuist begonnen aan een filter in getmail. Dat zal niet al te moeilijk zijn...

code:

Return-Path: <[e-mail]>
Received: from zink.protagonist.nl (unknown [127.0.0.1])
        by zink.protagonist.nl (Postfix) with ESMTP id F150A95F1EC5
        for <[e-mail]>; Wed, 22 Sep 2010 09:57:00 +0000 (UTC)

code:

Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from zink.protagonist.nl (unknown [127.0.0.1])
        by zink.protagonist.nl (Postfix) with ESMTP id F150A95F1EC5
        for <[e-mail]>; Wed, 22 Sep 2010 09:57:00 +0000 (UTC)

code:

MAIL FORWARDING
       For the sake of reliability, forwarded mail is  re-submit-
       ted  as  a new message, so that each recipient has a sepa-
       rate on-file delivery status record.

       In order to stop mail forwarding loops early, the software
       adds an optional Delivered-To: header with the final enve-
       lope recipient address. If mail arrives  for  a  recipient
       that is already listed in a Delivered-To: header, the mes-
       sage is bounced.

[Verwijderd]

En om het verhaal maar helemaal compleet te maken hier de aanpassing in één van de getmail configuratie files, aangevuld met een filter opdracht. Eén en ander loopt inmiddels weer naar volle tevredenheid...

code:

#
# /home/vmail/.getmail/p_turmac
#
# 20100925
#
[retriever]
type = SimplePOP3Retriever
server = pop.liemersmuseum.nl
username = [e-mail]
password = **********

[filter-prota]
type = Filter_external
path = /bin/sed
arguments = ('-f', '/home/vmail/.getmail/filter_prota')
ignore_stderr = true

[destination]
type = MDA_external
path = /usr/sbin/sendmail
arguments = ("-i", "[e-mail]")

[options]
verbose = 2
delivered_to = false
received = false
message_log = /var/log/getmail/log
message_log_verbose = true

#
# Do not delete email from provider during testing.
# Change to true when production started.
#
delete = true

#
# EOF
#

En de sed instructies in /home/vmail/.getmail/filter_prota zijn:

code:

/^X-Original-To:/d
/^Delivered-To:/d

Bedankt voor het meedenken allen.,,