exim wartet nicht zwischen wiederholten Versuchen bei Greylisting

Hallo Michael,

(Sorry, my German-speaking brain isn't creating thoughts at the moment. [:(])

What do you see when you try the following at the command line?

grep -B 1 -A 4 'begin retry' /var/storage/chroot-smtp/etc/exim.conf

The result I got was:

 # --- Retry section ------------------------------------------------------
 begin retry
 
 *         * F,2h,2m; G,16h,1h,1.5; F,3d,6h
 

* = all domains
* = all errors
F,2h,2m = Fixed, retry every 2 minutes for up to 2 hours.
G,16h,1h = Geometrically increasing, retry in 1 hour, 1.5 hours, 2.25 hours, etc. for up to 16 hours.
F,3d,6h = Retry every 6 hours up to 3 days.

After 3 days, the messages are bounced.

Does that match your exim.conf file?

MfG - Bob (Bitte auf Deutsch weiterhin.)

(Sorry, my German-speaking brain isn't creating thoughts at the moment. [:(])
(My English-speaking brain wasn't either so I put this in request in the German forum. [:)])

Hallo Bob,

Vielen Dank für Deine Hilfe! Das Ergebnis gibt mir die Sicherheit, dass auf meiner Seite alles korrekt eingestellt ist:

# --- Retry section ------------------------------------------------------
begin retry

*         * F,2h,2m; G,16h,1h,1.5; F,3d,6h

Habe das Problem inzwischen weiter analysiert. Der Fehler scheint nur bei der speziellen Gegenstelle aufzutreten. Interessant ist der reply code 457. Die anderen Gegenstellen melden 450 oder 451. Dort wird die reguläre Wartezeit von anfangs etwa 2 Minuten eingehalten.

Eine kurze Recherche hat ergeben, dass der reply code 457 zumindest unüblich ist. Die Frage ist: Wie müsste sich exim korrekt verhalten?

Meiner Meinung nach müssten die Einstellungen bei allen 4xx-Codes berücksichtigt werden. Damit wäre es ein Problem von Sophos, oder?

Danke für alle weiteren Infos und freundliche Grüsse,

Michael

I don't understand why freenet.de uses 457 when virtually no one else does.  Also, I just noticed that there are four different IPs for those four "Greylisted" attempts.  Usually, the FQDN in an MX record resolves to a single IP, but emig.freenet.de resolves to the four seen in your log.

I would think that exim is doing the right thing in this situation - making sure that all four MTAs are aware that your UTM is tying to send an email because the first one tried is randomly chosen. 

MfG - Bob (Bitte auf Deutsch weiterhin.)

Hallo Bob,

vielen Dank für deinen weiteren Hinweis. Die unterschiedlichen IPs waren mir gar nicht aufgefallen (da fast identisch). Das erklärt natürlich die direkt aufeinander folgenden Sendeversuche, allerdings meiner Meinung nach noch nicht den unmittelbaren Abbruch nach dem vierten Versuch.

Werde das Problem aber nun auf sich beruhen lassen, da freenet zwar gross, aber letztlich nicht bedeutend genug ist. Der ursprüngliche Empfänger ist auch über einen anderen Provider erreichbar. Vielleicht kann der Thread aber jemandem helfen, der das selbe oder ein ähnliches Problem hat.

Danke nochmals!

Freundliche Grüsse,

Michael

Hallo,

ich sehe das gleiche Verhalten mit Mails an @freenet.de. Da emig-v0. bis emig-v3.freenet.de (die Reverse-Auflösung der IPs) gleichwertig als MX-Record für freenet.de eingetragen sind, probiert die Sophos alle Ziele durch.

Bisher sind aber alle Mails irgendwann nach dem Greylist-Timeout zugestellt worden.

Bei anderen Providern mit mehreren MX Einträgen ist das Verhalten aber ähnlich (z.B. vodafone.de)

Gruß Nathan

Hallo,

ich sehe das gleiche Verhalten mit Mails an @freenet.de. Da emig-v0. bis emig-v3.freenet.de (die Reverse-Auflösung der IPs) gleichwertig als MX-Record für freenet.de eingetragen sind, probiert die Sophos alle Ziele durch.

Bisher sind aber alle Mails irgendwann nach dem Greylist-Timeout zugestellt worden.

Bei anderen Providern mit mehreren MX Einträgen ist das Verhalten aber ähnlich (z.B. vodafone.de)

Gruß Nathan