Hallo,

seit ein paar Tagen erzwingt Google, dass die Nachrichten mit SPF oder DKIM
überprüft werden können und lehnt andere Mails ab. Das war seit längerem
angekündigt und hatte ich auch erwartet.

Nicht erwartet hatte ich, dass täglich einige Hundert E-Mails von uns durch
Google abgelehnt werden. Es handelt sich dabei um Autoreplies
(Out-of-Office/Vacation-Meldungen), die mit leerem Envelope-Sender erzeugt
werden.

Die Ablehnung von Google an eine gmail.com-Adresse lautet:

550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26
550-5.7.26 Authentication results:
550-5.7.26 DKIM = did not pass
550-5.7.26 SPF [] with ip: [130.133.4.78] = did not pass
550-5.7.26
550-5.7.26 For instructions on setting up authentication, go to
550 5.7.26 https://support.google.com/mail/answer/81126#authentication [...]

Offenbar schreibt Google die Domain, die geprüft wird, in die eckigen
Klammern hinter "SPF" und listet auch unsere IP-Adresse, die dort erwartet
wird. In der obenstehenden Fehlermeldung gibt es aber keine Domain, denn
der Envelope-Sender ist <> und daher nichts in den eckigen Klammern. Weder
SPF noch DKIM, die beide auf dem Envelope-Sender arbeiten, können da
erfolgreich sein.

Exim hat in der Dokumentation:

27. THE AUTOREPLY TRANSPORT
[...]
To reduce the possibility of message cascades, messages created by the
autoreply transport always have empty envelope sender addresses, like
bounce messages.

Es wäre also gar nicht so einfach, an der Stelle etwas anderes als einen
leeren Envelope-Sender zu verwenden.

Was habe ich übersehen? Wir macht ihr das?

Heiko

Am 07.02.24 um 18:57 schrieb Heiko Schlichting:

> Was habe ich übersehen? Wir macht ihr das?

Hat der HELO-Name des ausgehenden Servers einen SPF-Eintrag?

Am 07.02.2024 17:57 Uhr schrieb Heiko Schlichting:

> Offenbar schreibt Google die Domain, die geprüft wird, in die eckigen
> Klammern hinter "SPF" und listet auch unsere IP-Adresse, die dort
> erwartet wird. In der obenstehenden Fehlermeldung gibt es aber keine
> Domain, denn der Envelope-Sender ist <> und daher nichts in den
> eckigen Klammern. Weder SPF noch DKIM, die beide auf dem
> Envelope-Sender arbeiten, können da erfolgreich sein.

Wenn MAIL FROM leer ist (<>), wird die Domain im EHLO/HELO für SPF
genutzt.

DKIM ist davon unabhängig. Das wird auf From: angewendet.
Das ist beim Bounce dann i.d.R. sowas wie
MAILER-DAEMON@server.example.org.

Da muss dann auch DKIM eingerichtet werden oder man signiert halt mit
der Parent-Domain.

--
Gruß
Marco

Spam und Werbung bitte an ichschickereklame@cartoonies.org

Markus Schaaf <mschaaf@elaboris.de> wrote:
> Am 07.02.24 um 18:57 schrieb Heiko Schlichting:
>
>> Was habe ich übersehen? Wir macht ihr das?
>
> Hat der HELO-Name des ausgehenden Servers einen SPF-Eintrag?

Der Hostname? Nein. Die Domain des Hostnamens schon.

In diesem Fall ist das der Server mit der IP 130.133.4.78 und dem Hostname
outpost3.zedat.fu-berlin.de, der auch beim EHLO verwendet wird. Für
zedat.fu-berlin.de gibt es einen SPF-Eintrag, weil es dort auch anmailbare
Adressen gibt. Für outpost3.zedat.fu-berlin.de gibt es bislang keinen
SPF-Eintrag.

Heiko

Am 08.02.2024 14:23 Uhr schrieb Heiko Schlichting:

> Markus Schaaf <mschaaf@elaboris.de> wrote:
> > Am 07.02.24 um 18:57 schrieb Heiko Schlichting:
> >
> >> Was habe ich übersehen? Wir macht ihr das?
> >
> > Hat der HELO-Name des ausgehenden Servers einen SPF-Eintrag?
>
> Der Hostname? Nein. Die Domain des Hostnamens schon.
>
> In diesem Fall ist das der Server mit der IP 130.133.4.78 und dem
> Hostname outpost3.zedat.fu-berlin.de, der auch beim EHLO verwendet
> wird. Für zedat.fu-berlin.de gibt es einen SPF-Eintrag, weil es dort
> auch anmailbare Adressen gibt. Für outpost3.zedat.fu-berlin.de gibt
> es bislang keinen SPF-Eintrag.

Dann musst du einen anlegen, wenn du willst, dass SPF hier funktioniert.

--
Gruß
Marco

Spam und Werbung bitte an ichschickereklame@cartoonies.org

Marco Moock <mm+solani@dorfdsl.de> wrote:
>
> Dann musst du einen anlegen, wenn du willst, dass SPF hier funktioniert.

Ja, sieht besser aus und Google nimmt entsprechende Mails jetzt offenbar
an. Dir und Markus Schaaf vielen Dank.

Heiko

Marco Moock <mm+solani@dorfdsl.de> wrote:
> Am 08.02.2024 14:23 Uhr schrieb Heiko Schlichting:
>> Markus Schaaf <mschaaf@elaboris.de> wrote:
> > Am 07.02.24 um 18:57 schrieb Heiko Schlichting:

>>>> Was habe ich übersehen? Wir macht ihr das?

>>> Hat der HELO-Name des ausgehenden Servers einen SPF-Eintrag?

>> Der Hostname? Nein. Die Domain des Hostnamens schon.

>> In diesem Fall ist das der Server mit der IP 130.133.4.78 und dem
>> Hostname outpost3.zedat.fu-berlin.de, der auch beim EHLO verwendet
>> wird. Für zedat.fu-berlin.de gibt es einen SPF-Eintrag, weil es dort
>> auch anmailbare Adressen gibt. Für outpost3.zedat.fu-berlin.de gibt
>> es bislang keinen SPF-Eintrag.

> Dann musst du einen anlegen, wenn du willst, dass SPF hier
> funktioniert.

Danke auch von mir, das war *exakt* die gleiche Frage (und aus dem
gleichen Grund im gleichen Umfeld), die sich mir auch stellte.

S°

--
Sigmentation fault. Core dumped.

Heiko Schlichting, 2024-02-07 18:57:

> Hallo,
>
> seit ein paar Tagen erzwingt Google, dass die Nachrichten mit SPF oder DKIM
> überprüft werden können und lehnt andere Mails ab. Das war seit längerem
> angekündigt und hatte ich auch erwartet.
>
> Nicht erwartet hatte ich, dass täglich einige Hundert E-Mails von uns durch
> Google abgelehnt werden. Es handelt sich dabei um Autoreplies
> (Out-of-Office/Vacation-Meldungen), die mit leerem Envelope-Sender erzeugt
> werden.
>
> Die Ablehnung von Google an eine gmail.com-Adresse lautet:
>
> 550-5.7.26 This mail has been blocked because the sender is unauthenticated.
> 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
> 550-5.7.26
> 550-5.7.26 Authentication results:
> 550-5.7.26 DKIM = did not pass
> 550-5.7.26 SPF [] with ip: [130.133.4.78] = did not pass

Übersetzt:

1. DKIM-Signatur ist nicht vorhanden oder fehlerhaft.

2. Die Mail wurde von 130.133.4.78 aus gesendet, aber es gibt keinen
passenden TXT-Record mit SPF-Eintrag in der Absenderdomain, der
130.133.4.78 als zulässigen Mailserver dafür authorisiert.

> 550-5.7.26
> 550-5.7.26 For instructions on setting up authentication, go to
> 550 5.7.26 https://support.google.com/mail/answer/81126#authentication [...]
>
> Offenbar schreibt Google die Domain, die geprüft wird, in die eckigen
> Klammern hinter "SPF" und listet auch unsere IP-Adresse, die dort erwartet
> wird. In der obenstehenden Fehlermeldung gibt es aber keine Domain, denn

Nein, die IP-Adresse wurde benutzt! Und Google erwartet, dass für diese
Adresse bei der Absenderdomain ein SPF-Eintrag vorhanden ist.

> der Envelope-Sender ist <> und daher nichts in den eckigen Klammern. Weder
> SPF noch DKIM, die beide auf dem Envelope-Sender arbeiten, können da
> erfolgreich sein.
>
> Exim hat in der Dokumentation:
>
> 27. THE AUTOREPLY TRANSPORT
> [...]
> To reduce the possibility of message cascades, messages created by the
> autoreply transport always have empty envelope sender addresses, like
> bounce messages.
>
> Es wäre also gar nicht so einfach, an der Stelle etwas anderes als einen
> leeren Envelope-Sender zu verwenden.
>
> Was habe ich übersehen? Wir macht ihr das?

Keinen Auto-Reply an E-Mail-Adresse außerhalb eurer Domain nutzen.
Ernsthaft. Sowas erzeugt nur Backscatter.

--
Arno Welzel
https://arnowelzel.de

Am 14.02.2024 schrieb Arno Welzel <usenet@arnowelzel.de>:

> Keinen Auto-Reply an E-Mail-Adresse außerhalb eurer Domain nutzen.
> Ernsthaft. Sowas erzeugt nur Backscatter.

Das ist leider je nach Umgebung nicht wirklich möglich. Speziell dann
nicht, wenn wer mit Entscheidungsgewalt es so will und als Steigerung
noch Backscatter nicht versteht.

Arno Welzel <usenet@arnowelzel.de> wrote:
> Keinen Auto-Reply an E-Mail-Adresse außerhalb eurer Domain nutzen.

Das ist keine Option. Dafür gibt es an einer großen Universität viel zu
viel Kommunikation mit anderen wissenschaftlichen Einrichtungen auf der
ganzen Welt. Kommunikation mit anderen ist ein wesentlicher Bestandteil im
Bereich Forschung.

> Sowas erzeugt nur Backscatter.

Bei erkanntem Spam (und das funktioniert mit unserem dreistufigen Verfahren
ziemlich gut) gibt es kein Auto-Reply. Natürlich auch nicht, wenn Mails
entsprechend RFC 3834 gekennzeichnet sind oder wenn an anderen Merkmalen
(Mailinglisten, no-reply-artiger Absender, Precedence o.ä.) ein Autoreply
unangebracht erscheint. Bei uns gibt es daher nicht nennenswert
Backscatter durch Autoreplies.

Aber grundsätzlich hast Du natürlich vollkommen recht und bei vielen
anderen Einrichtungen ist das leider ein Thema.

Heiko