[Postfixbuch-users] Integration von DSPAM

Sandy Drobic postfixbuch-users at japantest.homelinux.com
Di Jan 8 22:50:45 CET 2008


oskar-postfix at eyb.de wrote:
> Hi!
> 
> 
> Sandy Drobic schrieb am 08.01.2008 21:54:
>> oskar-postfix at eyb.de wrote:

>>> dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to 
>>> chuck.ath.cx[88.67.44.203]: Operation timed out)
>> Postfix versucht, eine Verbindung zum Host chuck.ath.cx aufzubauen, aber 
>> die Verbindung kommt nicht zustande. Ich hatte da gerade kein Problem, die 
>> Verbindung aufzubauen.
>>
>> Entweder der Host lief zu der Zeit nicht, 
> 
> Jep, der war mal kurze Zeit offline. Ich habe den Eindruck, dass sich 
> Postfix den Status merkt und auch bei postfix flush eine neue Zustellung 
> nicht wirklich probiert. Bei qmail konnte man das mit 

http://www.postfix.org/postconf.5.html#minimal_backoff_time

> /var/qmail/bin/qmail-tcpok zurücksetzen, ich vermute, bei Postfix ist 
> das ähnlich?

Nur, wenn die Mails entweder neu in die Queue gestellt werden mit 
"postsuper -r ALL" oder wenn minimal_backoff_time erreicht wird. Dies 
kannst du nach deinen Gegebenheiten einstellen. Ich habe sie auf 6 Minuten 
eingestellt, weil die meisten Greylister bis zu 5 Minuten setzen und so 
die Mails ohne große Verzögerung durchgeht.

>> oder Postfix hat noch andere 
>> Probleme, und dies war nur ein Symptom. Suche mal im Log nach sonstigen 
>> Fehlern:
> 
> grep '(panic|fatal|error|warning)' /var/log/maillog|wc -l
>     10977

Bleah! Ich nehme an, dass der Hauptanteil davon kaputte Zombie-Clients 
sind, die keinen sauberen Reverse-DNS haben?

postfix/smtpd[2782]: warning: 190.49.26.235: hostname 
190-49-26-235.speedy.com.ar verification failed: Name or service not known


> 
>>> Da sammelten sich 360 mails an, die ich nun alle mit
>>> delete_from_mailq.pl MAILER-DAEMON aus der queue geschmissen habe.
>> Alles Testnachrichten oder wie ein Backup > /dev/null? (^-^)
> 
> Schlimmer!
> 
> 9F0348B80A6     3858 Tue Jan  8 18:55:14  jgreenwood at pbgbuilders.com
> (host chuck.ath.cx[88.67.44.203] said: 450 4.1.1 <lineybmet at eyb.de>: 
> Recipient address rejected: User unknown in virtual mailbox table (in 
> reply t
> o RCPT TO command))
>                                           lineybmet at eyb.de
> 
> 
> wie gesacht,  lineybmet@ ist so ein evergreen.
> 
> auf beastie ist also noch die 450-mail von chuck (auf dem eyb.de ist) in 
> der queue, das sollte eigentlich garnichtmehr so sein wegen
> 
> unknown_local_recipient_reject_code = 550
> unknown_address_reject_code = 550
> 
> ????? :)

Du hast vermutlich das typische Problem von Gateway-Betreibern. Mails 
werden erst von dem Gateway-Server angenommen und dann an die 
dahinterliegenden Server weitergeleitet. Diese lehnen die Mails dann ab 
wegen irgendwelcher Gründe, und der arme Gateway-Server darf sie dann 
bouncen und wird in die Blacklisten aufgenommen.

Lösung:
Diese Policy muss durchgesetzt werden:
- Der Gatewayserver MUSS alle gültigen Empfänger kennen
- Mails, die von extern vom Gateway-Server angenommen werden, müssen von 
den dahinterliegenden Servern ebenfalls angenommen werden.

Dies kann geschehen, indem der Gateway-Server für alle Empfänger, die für 
den Server Chuck bestimmt sind (sollten dann in 
relay_domains/relay_recipient_maps sein), erst bei Chuck nachfragt, ob der 
sie auch nimmt. Das erledigt reject_unverified_recipient.

gateway:
relay_domains = relay.example.com
smtpd_recipient_restrictions =
	....
	reject_unauth_destination
	check_recipinet_access hash:/etc/postfix/relay_domain_check
transport_maps = hash:/etc/postfix/transport

etc/postfix/relay_domain_check:
relay.example.com	reject_unverified_recipient

/etc/postfix/transport:
relay.example.com	smtp:[chuck]


Postfix fragt dann erst bei chuck nach, ob der den Empfänger annehmen 
würde. Wenn ja, dann sagt auch Gateway dem einliefernden externen client, 
dass der Empfänger akzeptiert ist.

Sollte Chuck nicht antworten, wird die Mail temporär abgelehnt. Das ist 
die Gefahr dabei. Außerdem steigt natürlich die Last, da für jede 
eingehende Relaymail eine Probemail losgeschickt wird. Teilweise kann dies 
über einen Cache aufgefangen werden, der das Ergebnis dieser Probemails 
aufbewahrt.


-- 
Sandy

Antworten bitte nur in die Mailingliste!
PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com




Mehr Informationen über die Mailingliste Postfixbuch-users