Problem mit "From:" by mail()

[Robert Riebisch]

Moin!

Obwohl der Traffic auch in dieser NG nur noch spärlich ist, versuche ich
es hier mal.
Also: Ich habe auf meiner Webseite zwei Kontaktformulare. Eines ist in
Forumsoftware integriert, das andere habe ich mit ein wenig Abgucken
daraus abgeleitet und in ein separates Skript gesteckt.
Nun trete ich ja selten mit mir selbst in Kontakt, teste/nutze die
Formulare aber selten. Da ich meine Webseite aber umgezogen habe, fiel
mir beim Testen nun auf, dass die gesendeten Nachrichten bei mir NICHT
ankommen, sobald im Absender ("From:") das Wort "google" im Domainteil
vorkommt. Verwende ich hingegen "goggle", dann geht's. Als TLD ist
"google" auch okay.

Ich habe daraus folgenden Testcase gebaut:
<?php
$to = '...'; // eine meiner Adressen bei verschiedenen Providern
$subject = 'Test';
$message = 'Lorem ipsum dolor sit amet, consetetur sadipscing elitr.';
$headers = 'From: a...@googlemail.com';
@mail($to, $subject, $message, $headers)
?>
Für ich das Skript durch Aufrufen im Webbrowser auf, kommt die Mail
nicht an.

a...@xgooglemail.com -> geht
abc@.googlemail.com -> geht nicht
abc@,googlemail.com -> geht nicht
a...@1googlemail.com -> geht
a...@com.google.com -> geht nicht
a...@google.co.uk -> geht nicht
a...@googl.co.uk -> geht

Getestet habe ich es bei zwei Webspace-Providern mit PHP 7.4, 8.0 und
8.1. Im Testskript ist jetzt keine Fehlerbehandlung drin, aber im
ursprünglichen Skript schon. Und jedes Mal gibt mail() true zurück.

Irgendwo danach scheint eine Art RegExp "\bgoogle." drüberzulaufen und
irgendwie Google auszusortieren.

Könnt ihr das bei euch reproduzieren?
Und wo liegt die Ursache für dieses Verhalten?
Und was tut man dagegen?

--
Robert Riebisch

[Thomas Hochstein]

Robert Riebisch schrieb:

> Da ich meine Webseite aber umgezogen habe, fiel
> mir beim Testen nun auf, dass die gesendeten Nachrichten bei mir NICHT
> ankommen, sobald im Absender ("From:") das Wort "google" im Domainteil
> vorkommt.

[...]

> Ich habe daraus folgenden Testcase gebaut:
> <?php
> $to = '...'; // eine meiner Adressen bei verschiedenen Providern

Das Script bei Deinem Webhoster sendet also eine E-Mail mit dem Absender
"a...@googlemail.com" an Deine Mailadresse bei einem anderen Anbieter? Dann
ist es nicht wirklich überraschend, dass die Mail nicht ankommt (oder im
Spam landet).

Üblicherweise darf man heute erwarten, dass bei eingehender Mail auf SPF
und ggf. DKIM geprüft wird, d.h. geprüft wird, ob für die Absenderdomain
bestimmte berechtigte Mailserver hinterlegt sind und/oder Mails von der
Absenderdomain signiert sein müssen. Bei googlemail.com ist natürlich
beides der Fall. Mail mit einem Absender aus einer der Google-Domains muss
daher regelmäßig über die Mailinfrastruktur von Google laufen, um auch
anzukommen.

-thh

[Robert Riebisch]

Thomas Hochstein wrote:

>> Ich habe daraus folgenden Testcase gebaut:
>> <?php
>> $to = '...'; // eine meiner Adressen bei verschiedenen Providern
>
> Das Script bei Deinem Webhoster sendet also eine E-Mail mit dem Absender
> "a...@googlemail.com" an Deine Mailadresse bei einem anderen Anbieter? Dann
> ist es nicht wirklich überraschend, dass die Mail nicht ankommt (oder im
> Spam landet).

1. *Zwei*, voneinander unabhängige, Hoster.
2. Im Spam landet sie nie. Sie kommt einfach nicht an.

> Üblicherweise darf man heute erwarten, dass bei eingehender Mail auf SPF
> und ggf. DKIM geprüft wird, d.h. geprüft wird, ob für die Absenderdomain
> bestimmte berechtigte Mailserver hinterlegt sind und/oder Mails von der
> Absenderdomain signiert sein müssen. Bei googlemail.com ist natürlich

Das ist mir bekannt.
Nur trifft das auch im Falle der PHP-mail-Funktion zu?
Mein Hoster meint:
"Absender ist niemals der Absender, den Sie in Ihr Formular eintragen,
sondern stets der Webspace-User Ihres Kontos, also x...@yyy.de.
Der Absender, den Ihr Formular als Absender annimmt, spielt für den
Server keine Rolle.
Es besteht hier kein Fehler. Bitte lösen Sie den Fehler in Ihrer Software."

> beides der Fall. Mail mit einem Absender aus einer der Google-Domains muss
> daher regelmäßig über die Mailinfrastruktur von Google laufen, um auch
> anzukommen.

Kannst du mir einen weiteren Anbieter nennen, der analog zu
Google/Google Mail konfiguriert ist und wo es demzufolge auch nicht
klappen sollte? Ich würde das nämlich gern mal ausprobieren.

--
Robert Riebisch

[Arno Welzel]

Robert Riebisch:

[...]

> Ich habe daraus folgenden Testcase gebaut:
> <?php
> $to = '...'; // eine meiner Adressen bei verschiedenen Providern
> $subject = 'Test';
> $message = 'Lorem ipsum dolor sit amet, consetetur sadipscing elitr.';
> $headers = 'From: a...@googlemail.com';
> @mail($to, $subject, $message, $headers)
> ?>
> Für ich das Skript durch Aufrufen im Webbrowser auf, kommt die Mail
> nicht an.
>
> a...@xgooglemail.com -> geht

Die Domain "xgooglemail.com" ist zwar existent und hat einen MX, aber
hat nichts mit Google zu tun.

Siehe <https://arnowelzel.de/tools/dns-abfrage?dns_domain=xgooglemail.com>

Wonach hast Du hier "geht" definiert? Dass der MX die Mail nicht direkt
ablehnt? Dass @mail() keinen Fehler produziert?

> abc@.googlemail.com -> geht nicht

Ungültige Adresse mit "." im Domainpart am Anfang.

> abc@,googlemail.com -> geht nicht

Ungültige Adresse mit "," im Domainpart am Anfang

> a...@1googlemail.com -> geht

Was heißt "geht"? Auch diese Domain hat zwar einen MX - zufällig den
selben wie xgooglemail.com, hat aber auch nichts mit Google zu tun.

> a...@com.google.com -> geht nicht

com.google.com existiert nicht.

> a...@google.co.uk -> geht nicht

Was heißt "geht nicht"? Es ist nicht selten, dass große Anbieter Mails
von ihnen unbekannte IP-Adressen nicht akzeptieren. Generell sollte man
an Google eher nur via IPv4 senden und nicht IPv6. Weiterhin muss man
Dinge wie SPF, DMARC usw. beachten.

Teste mal deinen Server <https://mxtoolbox.com> bzgl. Blacklisting etc.

> a...@googl.co.uk -> geht

Was bedeutet "geht" hier?

Auch das hat nichts mit Google zu tun und diese Domain hat noch nicht
mal einen MX:

<https://arnowelzel.de/tools/dns-abfrage?dns_domain=googl.co.uk>

> Getestet habe ich es bei zwei Webspace-Providern mit PHP 7.4, 8.0 und
> 8.1. Im Testskript ist jetzt keine Fehlerbehandlung drin, aber im
> ursprünglichen Skript schon. Und jedes Mal gibt mail() true zurück.

Ja, mail() gibt immer true zurück, wenn PHP die mail an sendmail oder
den konfigurierten Smarthost loswerden konnte. Das hat *nicht* damit zu
tun, ob sie ankommt sondern bedeutet nur, dass die Empfängeradresse
formal gültig ist.

Siehe auch <https://www.php.net/manual/de/function.mail.php>.

Zitat:

"Gibt true zurück, wenn die E-Mail erfolgreich für den Versand
akzeptiert wurde, sonst false.

Dass eine E-Mail für den Versand akzeptiert wurde, bedeutet NICHT, dass
sie auch wirklich den gewünschten Empfänger erreichen wird."

> Irgendwo danach scheint eine Art RegExp "\bgoogle." drüberzulaufen und
> irgendwie Google auszusortieren.

Nein.

> Könnt ihr das bei euch reproduzieren?
> Und wo liegt die Ursache für dieses Verhalten?

Siehe oben.

> Und was tut man dagegen?

Lernen, wie E-Mail und SMTP technisch funktioniert.

--
Arno Welzel
https://arnowelzel.de

[Arno Welzel]

Arno Welzel:

> Robert Riebisch:
>
> [...]
>> Ich habe daraus folgenden Testcase gebaut:
>> <?php
>> $to = '...'; // eine meiner Adressen bei verschiedenen Providern
>> $subject = 'Test';
>> $message = 'Lorem ipsum dolor sit amet, consetetur sadipscing elitr.';
>> $headers = 'From: a...@googlemail.com';
>> @mail($to, $subject, $message, $headers)
>> ?>
>> Für ich das Skript durch Aufrufen im Webbrowser auf, kommt die Mail
>> nicht an.
>>
>> a...@xgooglemail.com -> geht
>
> Die Domain "xgooglemail.com" ist zwar existent und hat einen MX, aber
> hat nichts mit Google zu tun.

[...]

Korrektur: ich habe übersehen, dass Du mit verschiedenen ABSENDERN
getest hast. Damit nehme ich alles diesbezüglich zurück!

Aber dennoch:

Man darf nicht irgendeinen Schrott im "From:" angeben, sondern das
sollte eine formal gültige Adresse sein - also nichts, wo die Domain mit
"." oder "," anfängt.

Weiterhin muss der Server, der die E-Mail verschickt, auch berechtigt
sein, das zu tun. Faktisch prüfen fast alle großen Provider, ob der
Server in den SPF-Records der Domain vorkommt, die als Absendeadresse
verwendet wurde. Wenn Du also etwas als "@google.co.uk" oder
"@com.google.com" sendest, prüft der empfangende Server, ob bei den
Domains "google.co.uk" oder "google.com" ein SPF-Record existiert *und*
ob da *dein* Server genannt ist - und nachdem Google kaum *deinem*
Server erlauben wird, in ihrem Namen Mails zu senden, werden diese sehr
wahrscheinlich abgelehnt, weil der SPF-Record nicht passt.

Wenn Du also E-Mails senden willst, nutze dafür auch deine eigene
Domain, die deinem Server zugeordnet ist, als Absendeadresse.

Mehr zu SPF siehe hier:

<https://de.wikipedia.org/wiki/Sender_Policy_Framework>

[Arno Welzel]

Robert Riebisch:

> Thomas Hochstein wrote:
>
>>> Ich habe daraus folgenden Testcase gebaut:
>>> <?php
>>> $to = '...'; // eine meiner Adressen bei verschiedenen Providern
>>
>> Das Script bei Deinem Webhoster sendet also eine E-Mail mit dem Absender
>> "a...@googlemail.com" an Deine Mailadresse bei einem anderen Anbieter? Dann
>> ist es nicht wirklich überraschend, dass die Mail nicht ankommt (oder im
>> Spam landet).
>
> 1. *Zwei*, voneinander unabhängige, Hoster.
> 2. Im Spam landet sie nie. Sie kommt einfach nicht an.

Ja, das ist so üblich, wenn man die Regeln der Provider nicht beachtet.
Als echter Absender hättest Du eine Unzustellbarkeitsnachricht bekommen.
Ein PHP-Script bekommt sowas natürlich nicht, weil es die Mail einfach
an sendmail oder einen Server übergibt und sich um den Rest nicht weiter
kümmert.

>> Üblicherweise darf man heute erwarten, dass bei eingehender Mail auf SPF
>> und ggf. DKIM geprüft wird, d.h. geprüft wird, ob für die Absenderdomain
>> bestimmte berechtigte Mailserver hinterlegt sind und/oder Mails von der
>> Absenderdomain signiert sein müssen. Bei googlemail.com ist natürlich
>
> Das ist mir bekannt.
> Nur trifft das auch im Falle der PHP-mail-Funktion zu?

Ja, warum sollte das nicht zu zutreffen? Die Prüfung der E-Mail beim
*Empfänger* hängt ja nicht davon ab, welche Software sie beim Absender
versendet hat.

[Stefan Froehlich]

On Mon, 04 Apr 2022 12:54:21 Arno Welzel wrote:
> Faktisch prüfen fast alle großen Provider, ob der Server in den
> SPF-Records der Domain vorkommt, die als Absendeadresse verwendet
> wurde.

Zum Glück nicht.

Ich habe da einen Sonderfall, der unbedingt seine Mails mit
GMX-Absenderadresse über *meinen* Server verschickt haben möchte,
auch nach Aufklärung über die damit verbundenen Probleme.
Erstaunlicherweise erreichen dennoch geschätzte 90% der so
verschickten Emails den gewünschten Empfänger.

Tun sollte man derartiges natürlich trotzdem nicht, schon klar.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Schmatzen mit Stefan - herzlich werden mit Vergnügen.
(Sloganizer)

[Robert Riebisch]

Arno Welzel wrote:

>>> Das Script bei Deinem Webhoster sendet also eine E-Mail mit dem Absender
>>> "a...@googlemail.com" an Deine Mailadresse bei einem anderen Anbieter? Dann
>>> ist es nicht wirklich überraschend, dass die Mail nicht ankommt (oder im
>>> Spam landet).
>>
>> 1. *Zwei*, voneinander unabhängige, Hoster.
>> 2. Im Spam landet sie nie. Sie kommt einfach nicht an.
>
> Ja, das ist so üblich, wenn man die Regeln der Provider nicht beachtet.
> Als echter Absender hättest Du eine Unzustellbarkeitsnachricht bekommen.
> Ein PHP-Script bekommt sowas natürlich nicht, weil es die Mail einfach
> an sendmail oder einen Server übergibt und sich um den Rest nicht weiter
> kümmert.

Okay.

Das "Tolle" ist ja, dass das originale Kommentar-Skript nach dem (immer)
erfolgreichen mail()-Aufruf (Versand einer Nachricht an mich), direkt im
Anschluss noch per weiterem mail()-Aufruf eine Erfolgsmail an den
Besucher verschickt. Handelt es sich bei der Mailadresse des Besuchers
um keine real existierende Adresse, schlägt bei mir eine "Undelivered
Mail"-Nachricht auf. D. h., von jedem Spammer werde ich neuerdings 2x
belästigt. Das war beim alten Hoster nicht der Fall. Wie auch immer, die
das technisch geregelt haben.

>>> Üblicherweise darf man heute erwarten, dass bei eingehender Mail auf SPF
>>> und ggf. DKIM geprüft wird, d.h. geprüft wird, ob für die Absenderdomain
>>> bestimmte berechtigte Mailserver hinterlegt sind und/oder Mails von der
>>> Absenderdomain signiert sein müssen. Bei googlemail.com ist natürlich
>>
>> Das ist mir bekannt.
>> Nur trifft das auch im Falle der PHP-mail-Funktion zu?
>
> Ja, warum sollte das nicht zu zutreffen? Die Prüfung der E-Mail beim
> *Empfänger* hängt ja nicht davon ab, welche Software sie beim Absender
> versendet hat.

Da hast du Recht.
Ich hatte mich da fälschlicherweise auf eine bestimmte Richtung
eingeschossen, weil ich ursprünglich ja nur das Versenden über das
Kontaktformular an eigene Adressen getestet habe, deren Domain beim
selben Hoster liegt.

--
Robert Riebisch

[Robert Riebisch]

Arno Welzel wrote:

>> a...@xgooglemail.com -> geht
>
> Die Domain "xgooglemail.com" ist zwar existent und hat einen MX, aber
> hat nichts mit Google zu tun.
>
> Siehe <https://arnowelzel.de/tools/dns-abfrage?dns_domain=xgooglemail.com>

Ok. Ich hatte nicht geprüft, ob die Domain existiert. Ich wollte einfach
nur irgendetwas testen, was (nicht nur) "google" im Namen hatte.

Was hat der MXer damit zu tun? Spannender wäre doch der SPF-Eintrag, oder?

> Wonach hast Du hier "geht" definiert? Dass der MX die Mail nicht direkt
> ablehnt? Dass @mail() keinen Fehler produziert?

Ähm, sorry, dass ich da nicht eindeutig war. Meine Definitation von
"geht" lautet: Nachricht kommt im Zielpostfach an.

>> a...@1googlemail.com -> geht
>
> Was heißt "geht"? Auch diese Domain hat zwar einen MX - zufällig den

Siehe oben.

> selben wie xgooglemail.com, hat aber auch nichts mit Google zu tun.

Ich habe nirgends das Gegenteil bekommt.

>> a...@com.google.com -> geht nicht
>
> com.google.com existiert nicht.

Ja, und? Muss sie denn existieren, wenn sie lediglich als Absender
dienen soll?

>> a...@google.co.uk -> geht nicht
>
> Was heißt "geht nicht"? Es ist nicht selten, dass große Anbieter Mails

Geht nicht = Mail kommt nicht im Zielpostfach an.

> von ihnen unbekannte IP-Adressen nicht akzeptieren. Generell sollte man
> an Google eher nur via IPv4 senden und nicht IPv6. Weiterhin muss man
> Dinge wie SPF, DMARC usw. beachten.

Ich will doch eigentlich gar nicht an Google senden. Die Google-Adressen
sind doch nur der *Absender*.

> Teste mal deinen Server <https://mxtoolbox.com> bzgl. Blacklisting etc.
>
>> a...@googl.co.uk -> geht
>
> Was bedeutet "geht" hier?

siehe oben

> Auch das hat nichts mit Google zu tun und diese Domain hat noch nicht
> mal einen MX:
>
> <https://arnowelzel.de/tools/dns-abfrage?dns_domain=googl.co.uk>
>
>> Getestet habe ich es bei zwei Webspace-Providern mit PHP 7.4, 8.0 und
>> 8.1. Im Testskript ist jetzt keine Fehlerbehandlung drin, aber im
>> ursprünglichen Skript schon. Und jedes Mal gibt mail() true zurück.
>
> Ja, mail() gibt immer true zurück, wenn PHP die mail an sendmail oder
> den konfigurierten Smarthost loswerden konnte. Das hat *nicht* damit zu
> tun, ob sie ankommt sondern bedeutet nur, dass die Empfängeradresse
> formal gültig ist.

Verstanden.

>> Irgendwo danach scheint eine Art RegExp "\bgoogle." drüberzulaufen und
>> irgendwie Google auszusortieren.
>
> Nein.

Doch! ;-)
Das Problem scheint sich gerade zu klären.
Die Nachrichten kommen schon im Zielpostfach an, landen dort aber im
Ordner "Spam", der nur per IMAP/Webmail sichtbar ist und wo ich sonst
auch nicht reinschaue, weil ich ausschließlich POP3 verwende und weil im
Spamfilter für das Postfach kein "Wegsortieren" eingestellt ist. Auch
ein Abschalten des Spamfilters hat nicht geholfen. Ich habe das erneut
an meinen Hoster weitergegeben.

>> Könnt ihr das bei euch reproduzieren?
>> Und wo liegt die Ursache für dieses Verhalten?
>
> Siehe oben.
>
>> Und was tut man dagegen?
>
> Lernen, wie E-Mail und SMTP technisch funktioniert.

Im Großen und Ganzen weiß ich das.
Die Frage ist aber offenbar eher, wie ich das Wissen in einem
PHP-Kontaktformular richtig einsetze. Sachdienliche Hinweise/Links zu
aktueller Literatur zu dem Thema nehme ich gern entgegen. :-)

--
Robert Riebisch

[Robert Riebisch]

Arno Welzel wrote:

>> Die Domain "xgooglemail.com" ist zwar existent und hat einen MX, aber
>> hat nichts mit Google zu tun.
> [...]
>
> Korrektur: ich habe übersehen, dass Du mit verschiedenen ABSENDERN
> getest hast. Damit nehme ich alles diesbezüglich zurück!

Ich ahnte doch, dass wir aneinander vorbeireden. ;-)

> Aber dennoch:
>
> Man darf nicht irgendeinen Schrott im "From:" angeben, sondern das
> sollte eine formal gültige Adresse sein - also nichts, wo die Domain mit
> "." oder "," anfängt.

Jo.

> Weiterhin muss der Server, der die E-Mail verschickt, auch berechtigt
> sein, das zu tun. Faktisch prüfen fast alle großen Provider, ob der
> Server in den SPF-Records der Domain vorkommt, die als Absendeadresse
> verwendet wurde. Wenn Du also etwas als "@google.co.uk" oder
> "@com.google.com" sendest, prüft der empfangende Server, ob bei den
> Domains "google.co.uk" oder "google.com" ein SPF-Record existiert *und*
> ob da *dein* Server genannt ist - und nachdem Google kaum *deinem*
> Server erlauben wird, in ihrem Namen Mails zu senden, werden diese sehr
> wahrscheinlich abgelehnt, weil der SPF-Record nicht passt.
>
> Wenn Du also E-Mails senden willst, nutze dafür auch deine eigene
> Domain, die deinem Server zugeordnet ist, als Absendeadresse.
>
> Mehr zu SPF siehe hier:
>
> <https://de.wikipedia.org/wiki/Sender_Policy_Framework>

Ich weiß, was SPF ist. (Wenn auch vielleicht nicht bis in letzte Detail.)

Gänzlich unerklärlich war ja für mich, dass über mail() versendete
Nachrichten *VON* 'vorname....@gmail.com' problemlos im
Zielpostfach angekommen sind, während 'vorname....@googlemail.com'
eben nicht ankam.
Diese beiden Postfächer sind ja bei Gmail/Google Mail identisch.
Beide Domains haben auch identische SPF Records. Also kann SPF keine
Erklärung für das unterschiedliche Verhalten sein.

TXT
v=spf1 redirect=_spf.google.com

_spf TXT
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com
include:_netblocks3.google.com ~all

TXT
v=spf1 include:_spf.google.com ~all

--
Robert Riebisch

[Matthias P. Würfl]

Robert Riebisch schrieb am Montag, 4. April 2022 um 21:14:03 UTC+2:

> >> Irgendwo danach scheint eine Art RegExp "\bgoogle." drüberzulaufen und
> >> irgendwie Google auszusortieren.
> >
> > Nein.
>
> Doch! ;-)

Nein.

Das wichtige ist erstmal zu verstehen, dass das Problem nicht bei PHP liegt, sondern dass die Mails nach dem Aufruf von mail() an Mailserver übergeben werden, welche auch noch etwas tun. Genaugenommen machen die alles und das mail() macht nichts. Das bedeutet es ist ganz und gar kein Problem von/in PHP, sondern eines welches mit diesen Mails unabhängig von PHP existiert.

> > Lernen, wie E-Mail und SMTP technisch funktioniert.
> Im Großen und Ganzen weiß ich das.
> Die Frage ist aber offenbar eher, wie ich das Wissen in einem
> PHP-Kontaktformular richtig einsetze.

Wichtig ist "SPF" und "DMARC Alignment". Wenn Du noch DKIM Signing hinbekommst, dann ist gut.

Sprich: Du hast eine Domain. Du wählst das "From" von dieser Domain. Du wählst den "Sender" auch von dieser Domain. Du machst einen SPF-Eintrag, dass Mails von der Domain von dem ausgehenden Mailserver gesendet werden können. Und dann machst Du noch DKIM-Signing für die Domain. Dann geht's. Ansonsten ist das halt Glückssache. Du kannst nicht erwarten, dass Mails die *Du* von *Deinem* Server verschickst und einen Absender tragen, dessen Domainteil "fremd" ist, beim Empfänger ankommen. Das sieht ja ein Blinder mit Krückstock, dass die Mail von Deinem Server kommt und nicht von "Google". Dann landet die Mail auf dem gleichen Haufen wie die anderen, die behaupten von "Sparkasse", "Paypal", "Microsoft" o.ä. zu sein und es offensichtlich nicht sind. Verifizierung des Absenders ist die erste und wichtigste Verteidigungslinie im Kampf gegen Spam.

Grüße, Matthias

[Karl Pflästerer]

[...]

Und hier sieht der Blinde schlicht das Falsche. SPF prüft den
return-path (Envelope From). Was im Absender steht, ist davon
unabhängig. Es ist eine absolut gängige Kombination, dass Absender (im
header) und Return-Path abweichen. Wer dies als Spam ausfiltert, ist
selbst schuld. (deshalb ist SPF auch oftmals problematisch für Mailing
Listen, aber auch andere Mail Weiterleitungen). (wenn dann noch der
Sender Header verwendet wird (absolut RFC konform) kommen noch mehr
solcher Spam-Checker, die solche Kombinationen nicht berücksichtigen, in
Schwierigkeiten (false positive)


KP

[Matthias P. Würfl]

Karl Pflästerer schrieb am Mittwoch, 6. April 2022 um 08:30:41 UTC:
> Matthias P. Würfl <matt...@wuerfl.com> writes:
>
> > Sprich: Du hast eine Domain. Du wählst das "From" von dieser Domain. Du wählst
> > den "Sender" auch von dieser Domain. Du machst einen SPF-Eintrag, dass Mails
> > von der Domain von dem ausgehenden Mailserver gesendet werden können. Und dann
> > machst Du noch DKIM-Signing für die Domain. Dann geht's. Ansonsten ist das
> > halt Glückssache. Du kannst nicht erwarten, dass Mails die *Du* von *Deinem*
> > Server verschickst und einen Absender tragen, dessen Domainteil "fremd" ist,
> > beim Empfänger ankommen. Das sieht ja ein Blinder mit Krückstock, dass die
> > Mail von Deinem Server kommt und nicht von "Google". Dann landet die Mail auf
> [...]
>
> Und hier sieht der Blinde schlicht das Falsche. SPF prüft den
> return-path (Envelope From). Was im Absender steht, ist davon
> unabhängig. Es ist eine absolut gängige Kombination, dass Absender (im
> header) und Return-Path abweichen.

Diese Kombination ist vor allen Dingen bei Spammern beliebt, weil die oft irgendwelche kaputten Web-Formulare nutzen um ihre Nachrichten loszuwerden. Deshalb werden diese Mails von Gott und der Welt schon seit Urzeiten rausgefiltert.

> Wer dies als Spam ausfiltert, ist
> selbst schuld.

Dann sag das Google, Yahoo, Microsoft, Facebook, AOL, PayPal und LinkedIn, die haben das eingeführt und machen das so. Den Robert interessiert ja, dass das Google ist, welches seine Mails rausfiltert und mit welcher Begründung. Ob Google das „falsch sieht“ oder „selbst dran schuld“ ist, das ist ja eine andere Debatte. Sie machen das halt so, kommunizieren das, standardisieren das (unter dem Namen „DMARC“). Da ist das unter dem Abschnitt „Alignment“ (in der deutschen Wikipedia unter dem Abschnitt „Kritik“) genau beschrieben. Das setzen grob 80% aller Mailserver (nach Volumen gerechnet) um ... womit wir beim Ausgangspunkt wären: Google filtert das raus.

Die Fragen, die Robert gestellt hatte:

> Könnt ihr das bei euch reproduzieren?

Ja, kenne ich in- und auswendig. Schon 1000 mal passiert.

> Und wo liegt die Ursache für dieses Verhalten?

Am fehlenden DMARC-Alignment.

> Und was tut man dagegen?

Zusehen, dass Return-Path und From übereinstimmen (zumindest von der Domain her), und dass SPF oder DKIM dazu passen.

Grüße, Matthias

[Karl Pflästerer]

Matthias P. Würfl <matt...@wuerfl.com> writes:

> Karl Pflästerer schrieb am Mittwoch, 6. April 2022 um 08:30:41 UTC:
>> Matthias P. Würfl <matt...@wuerfl.com> writes:
>>
>> > Sprich: Du hast eine Domain. Du wählst das "From" von dieser Domain. Du wählst
>> > den "Sender" auch von dieser Domain. Du machst einen SPF-Eintrag, dass Mails
>> > von der Domain von dem ausgehenden Mailserver gesendet werden können. Und dann
>> > machst Du noch DKIM-Signing für die Domain. Dann geht's. Ansonsten ist das
>> > halt Glückssache. Du kannst nicht erwarten, dass Mails die *Du* von *Deinem*
>> > Server verschickst und einen Absender tragen, dessen Domainteil "fremd" ist,
>> > beim Empfänger ankommen. Das sieht ja ein Blinder mit Krückstock, dass die
>> > Mail von Deinem Server kommt und nicht von "Google". Dann landet die Mail auf
>> [...]
>>
>> Und hier sieht der Blinde schlicht das Falsche. SPF prüft den
>> return-path (Envelope From). Was im Absender steht, ist davon
>> unabhängig. Es ist eine absolut gängige Kombination, dass Absender (im
>> header) und Return-Path abweichen.
>

> Diese Kombination ist vor allen Dingen bei Spammern beliebt,[...]

IBTD
Wir versenden hier nicht wenige Mails und Newsletter. Da ist dies eine
absolute Standard-Kombination. Und die Mails kommen mehrheitlich an

>
>> Wer dies als Spam ausfiltert, ist
>> selbst schuld.
>
> Dann sag das Google, Yahoo, Microsoft, Facebook, AOL, PayPal und
> LinkedIn, die

Auch bei denen wird man seine Mails mehrheitlich los. t-online ist
manchmal schwieriger.

[Matthias P. Würfl]

Karl Pflästerer schrieb am Donnerstag, 7. April 2022 um 12:58:47 UTC:

> >> Und hier sieht der Blinde schlicht das Falsche. SPF prüft den
> >> return-path (Envelope From). Was im Absender steht, ist davon
> >> unabhängig. Es ist eine absolut gängige Kombination, dass Absender (im
> >> header) und Return-Path abweichen.
> >
> > Diese Kombination ist vor allen Dingen bei Spammern beliebt,[...]
>
> IBTD
> Wir versenden hier nicht wenige Mails und Newsletter. Da ist dies eine
> absolute Standard-Kombination. Und die Mails kommen mehrheitlich an

OK, jetzt wird's interessant.

Also alle Domain haben bei uns einen SPF-Record, der verbietet, dass von anderen Servern aus Mails versendet werden. Wenn jetzt jemand unserer Kunden (also jemand, der eigentlich unsere Mailserver nutzt und die Domain bei uns liegen hat und der demzufolge genannte SPF-Einträge standardmäßig hat) zu einem externen Dienstleister geht und sich von dem Mails verschicken lässt, dann kommen die nur zu einem sehr kleinen Teil an. Oder - und das machen die größeren Dienstleister so - sagen direkt: das geht nicht. Wir müssen dann einen SPF-Include setzen, damit das From (!) der Mail von dem Server des Dienstleisters gesendet werden kann.

Andersherum: Jede Website hat bei uns einen "Sender", welcher in der PHP-Konfiguration hinterlegt ist. Wenn das nicht der Fall ist, dann wird ein Standard-Sender benutzt, welcher dann nicht mit dem From übereinstimmt. Wenn da Mails nicht ankommen, dann sagen ich den Kunden die sollen ein Standard-Postfach aussuchen und anschließend geht's dann.

Wenn das Hosting bei uns ist und die Domain samt Mail-Hosting wo anders, dann haben wir mit den Mails von der Website oft Probleme. Das macht so viele Probleme, dass wir mittlerweile eine Maildomain als Pflicht bei uns haben. Also wenn der Kunde Mails @osst.de annimmt und die Website unter www.osst.de ist, dann machen wir eine Maildomain @www.osst.de, über welche die Mails der Website verschickt werden. Klar funktioniert das vereinzelt, aber nicht gut genug für einen zuverlässigen Versand der Mails (nicht im Sinne von Bulkmails, sondern im Sinne von "wichtige Bestellung")

Wie gesagt alles bei SPF-Records, die das auch explizit verbieten. Hast Du vielleicht nur ein Soft Reject, dass Deine Erfahrungen da so anders sind?

Grüße, Matthias

[Arno Welzel]

Stefan Froehlich:

> On Mon, 04 Apr 2022 12:54:21 Arno Welzel wrote:
>> Faktisch prüfen fast alle großen Provider, ob der Server in den
>> SPF-Records der Domain vorkommt, die als Absendeadresse verwendet
>> wurde.
>
> Zum Glück nicht.
>
> Ich habe da einen Sonderfall, der unbedingt seine Mails mit
> GMX-Absenderadresse über *meinen* Server verschickt haben möchte,
> auch nach Aufklärung über die damit verbundenen Probleme.
> Erstaunlicherweise erreichen dennoch geschätzte 90% der so
> verschickten Emails den gewünschten Empfänger.

Das war dann wohl eher Zufall. Bei GMail und faktisch allen von
Microsoft gehosteten Domains (outlook.com, Hotmail etc.) ist die
Verwendung von Domains, wo der SPF-Record nicht zum Server passt, ein
zuverlässiger Weg für Unzustellbarkeit oder mindestens Aussortieren als
Spam.

[Arno Welzel]

Robert Riebisch:

> Arno Welzel wrote:
[...]

>> Mehr zu SPF siehe hier:
>>
>> <https://de.wikipedia.org/wiki/Sender_Policy_Framework>
>
> Ich weiß, was SPF ist. (Wenn auch vielleicht nicht bis in letzte Detail.)

Das hättest Du im Ausgangspost erwähnen können.

Die Tatsache, dass Du Dich wunderst, dass manche E-Mails gehen und
manche nicht, wenn Du von *deinem* Webspace aus Domains nutzt, die dort
*nicht* liegen, wirkte eher so, als wäre Dir SPF und die Praktiken
großer Mailprovider unbekannt.

> Gänzlich unerklärlich war ja für mich, dass über mail() versendete
> Nachrichten *VON* 'vorname....@gmail.com' problemlos im
> Zielpostfach angekommen sind, während 'vorname....@googlemail.com'
> eben nicht ankam.
> Diese beiden Postfächer sind ja bei Gmail/Google Mail identisch.
> Beide Domains haben auch identische SPF Records. Also kann SPF keine
> Erklärung für das unterschiedliche Verhalten sein.

Wenn Du SPF und Blacklisting von IP-Adressen nicht als Erklärung siehst,
musst Du die Betreiber der Postfächer fragen, wo die Mails nicht
ankommen, warum das so ist. Nur die Server-Administratoren können das
letztlich sagen.

[Robert Riebisch]

Arno Welzel wrote:

>> Ich weiß, was SPF ist. (Wenn auch vielleicht nicht bis in letzte Detail.)
>
> Das hättest Du im Ausgangspost erwähnen können.

Ja, schon, aber... Ich wollte euch mit (m)einer Aussage dazu nicht
gleich in eine bestimmte Richtung bei der Ursachenforschung lenken.
"Seltsamerweise" seid ihr, genau wie ich, gleich bei SPF gewesen. Wir
sehen, Erfahrung kann auch hinderlich sein.

> Die Tatsache, dass Du Dich wunderst, dass manche E-Mails gehen und
> manche nicht, wenn Du von *deinem* Webspace aus Domains nutzt, die dort
> *nicht* liegen, wirkte eher so, als wäre Dir SPF und die Praktiken
> großer Mailprovider unbekannt.

Ich wunderte mich vornehmlich, weil es vorher ~10 Jahre lang lief.
Zumindest theoretisch, weil ich ja nicht mehr nachvollziehen kann, was
/nicht/ ankam.

> Wenn Du SPF und Blacklisting von IP-Adressen nicht als Erklärung siehst,
> musst Du die Betreiber der Postfächer fragen, wo die Mails nicht
> ankommen, warum das so ist. Nur die Server-Administratoren können das
> letztlich sagen.

Die sagen halt immer nur, es würde kein Fehler vorliegen und ich solle
meine Skripte checken. Deswegen bin ich hier in der NG aufgeschlagen.

siehe auch meine Nachricht vom 04.04.: <t2fg1q$2hp$1...@dont-email.me>

--
Robert Riebisch

[Robert Riebisch]

Matthias P. Würfl wrote:

>> >> Irgendwo danach scheint eine Art RegExp "\bgoogle." drüberzulaufen und
>> >> irgendwie Google auszusortieren.
>> >
>> > Nein.
>>
>> Doch! ;-)
>
> Nein.

Doch! ;-)
(Wenn auch nicht in PHP.)

> Das wichtige ist erstmal zu verstehen, dass das Problem nicht bei PHP
> liegt, sondern dass die Mails nach dem Aufruf von mail() an Mailserver
> übergeben werden, welche auch noch etwas tun. Genaugenommen machen die

Jo. Deswegen habe ich hier gepostet, weil mein PHP schon etwas
eingerostet ist.

> alles und das mail() macht nichts. Das bedeutet es ist ganz und gar kein
> Problem von/in PHP, sondern eines welches mit diesen Mails unabhängig
> von PHP existiert.

Genau. Das ist nun klar.

>> > Lernen, wie E-Mail und SMTP technisch funktioniert.
>> Im Großen und Ganzen weiß ich das.
>> Die Frage ist aber offenbar eher, wie ich das Wissen in einem
>> PHP-Kontaktformular richtig einsetze.
>
> Wichtig ist "SPF" und "DMARC Alignment". Wenn Du noch DKIM Signing
> hinbekommst, dann ist gut.

OK, danke.

> Sprich: Du hast eine Domain. Du wählst das "From" von dieser Domain.

Klar, z. B. "no-reply@...".

> Du wählst den "Sender" auch von dieser Domain. Du machst einen

OK

> SPF-Eintrag, dass Mails von der Domain von dem ausgehenden Mailserver
> gesendet werden können. Und dann machst Du noch DKIM-Signing für die

SPF jibbet schon.
DKIM muss ich mir ansehen.

> Domain. Dann geht's. Ansonsten ist das halt Glückssache. Du kannst nicht
> erwarten, dass Mails die *Du* von *Deinem* Server verschickst und einen
> Absender tragen, dessen Domainteil "fremd" ist, beim Empfänger ankommen.

Jo, hat dann also eher nur zufällig 10 Jahre lang funktioniert.

> Das sieht ja ein Blinder mit Krückstock, dass die Mail von Deinem Server
> kommt und nicht von "Google". Dann landet die Mail auf dem gleichen
> Haufen wie die anderen, die behaupten von "Sparkasse", "Paypal",
> "Microsoft" o.ä. zu sein und es offensichtlich nicht sind. Verifizierung
> des Absenders ist die erste und wichtigste Verteidigungslinie im Kampf
> gegen Spam.

Ja, aber... Mein Hoster meint, es wäre dem Server egal, was ich bei
From: eintragen würde. Es würde eh immer der User, unter dem der
Webserver läuft als (echter) Absender verwendet.

Bin da unter Linux nicht so bewundert, eher mit Exchange unterwegs
(gewesen). Heißt Letzteres evtl., dass sich der Webserveruser quasi
gegenüber dem Mailserver authentifiziert und weil das immer erfolgreich
ist, die Mail als interne Mail behandelt wird und deswegen an
Filtersystemen (meines Hosters) vorbeigehen sollte/könnte?

--
Robert Riebisch

[Robert Riebisch]

Matthias P. Würfl wrote:

>> Wer dies als Spam ausfiltert, ist
>> selbst schuld.
>
> Dann sag das Google, Yahoo, Microsoft, Facebook, AOL, PayPal und
> LinkedIn, die haben das eingeführt und machen das so. Den Robert
> interessiert ja, dass das Google ist, welches seine Mails rausfiltert
> und mit welcher Begründung. Ob Google das „falsch sieht“ oder „selbst
> dran schuld“ ist, das ist ja eine andere Debatte. Sie machen das halt
> so, kommunizieren das, standardisieren das (unter dem Namen „DMARC“). Da
> ist das unter dem Abschnitt „Alignment“ (in der deutschen Wikipedia
> unter dem Abschnitt „Kritik“) genau beschrieben. Das setzen grob 80%
> aller Mailserver (nach Volumen gerechnet) um ... womit wir beim
> Ausgangspunkt wären: Google filtert das raus.

Stopp! Hier liegt ein Missverständnis vor. Nicht Google filtert meine
Mails aus. Der Mailserver meines Hosters packt Mails, die über das
Kontaktformular von meinem Webspace ebenda versendet werden und im From:
ein "@google" haben in den Spam-Ordner meines Postfachs. Selbst wenn der
Spamfilter für dieses Postfach deaktiviert ist.

> Die Fragen, die Robert gestellt hatte:
>
>> Könnt ihr das bei euch reproduzieren?
>
> Ja, kenne ich in- und auswendig. Schon 1000 mal passiert.

Genau deswegen hast du aber vermutlich mein Skript gar nicht
ausprobiert. Wie wir nun wissen, hätte das aber auch nichts genützt,
weil das Problem irgendwo bei meinem Hoster liegt.

--
Robert Riebisch

[Arno Welzel]

Robert Riebisch:

> Arno Welzel wrote:
>
>>> Ich weiß, was SPF ist. (Wenn auch vielleicht nicht bis in letzte Detail.)
>>
>> Das hättest Du im Ausgangspost erwähnen können.
>
> Ja, schon, aber... Ich wollte euch mit (m)einer Aussage dazu nicht
> gleich in eine bestimmte Richtung bei der Ursachenforschung lenken.
> "Seltsamerweise" seid ihr, genau wie ich, gleich bei SPF gewesen. Wir
> sehen, Erfahrung kann auch hinderlich sein.

Wenn man weiß, was Du bereits berücksichtigt hast, kann man sich genau
das sparen.

[...]

>> Wenn Du SPF und Blacklisting von IP-Adressen nicht als Erklärung siehst,
>> musst Du die Betreiber der Postfächer fragen, wo die Mails nicht
>> ankommen, warum das so ist. Nur die Server-Administratoren können das
>> letztlich sagen.
>
> Die sagen halt immer nur, es würde kein Fehler vorliegen und ich solle
> meine Skripte checken. Deswegen bin ich hier in der NG aufgeschlagen.

Welche Betreiber sind denn das? Oder ist das eine vetrauliche Angabe?

[Arno Welzel]

Robert Riebisch:

[...]

> Stopp! Hier liegt ein Missverständnis vor. Nicht Google filtert meine
> Mails aus. Der Mailserver meines Hosters packt Mails, die über das
> Kontaktformular von meinem Webspace ebenda versendet werden und im From:
> ein "@google" haben in den Spam-Ordner meines Postfachs. Selbst wenn der
> Spamfilter für dieses Postfach deaktiviert ist.

Also nochmal langsam:

1) Du hast ein Kontaktformular, was Eingaben per E-Mail weiterleitet.

2) Die E-Mail geht *nicht* an den MX der Empfangsadresse, sondern
generell an den Mailserver eines Hosters.

3) Der Hoster verwirft die E-Mail, wenn sie bestimmte Absenderdomains hat.

Korrekt so?

[Robert Riebisch]

Arno Welzel wrote:

>> Stopp! Hier liegt ein Missverständnis vor. Nicht Google filtert meine
>> Mails aus. Der Mailserver meines Hosters packt Mails, die über das
>> Kontaktformular von meinem Webspace ebenda versendet werden und im From:
>> ein "@google" haben in den Spam-Ordner meines Postfachs. Selbst wenn der
>> Spamfilter für dieses Postfach deaktiviert ist.
>
> Also nochmal langsam:
>
> 1) Du hast ein Kontaktformular, was Eingaben per E-Mail weiterleitet.

Ja.

> 2) Die E-Mail geht *nicht* an den MX der Empfangsadresse, sondern
> generell an den Mailserver eines Hosters.

Ich bin nicht sicher, wie du das meinst.
Das Formular nutzt, wie in früheren Postings gesagt, die mail()-Funktion
von PHP. Was die im Hintergrund veranstaltet, weiß ich natürlich nicht.

Als *Empfänger* ist eine meiner Adressen meiner Domain bei diesem meinem
Hoster angegeben.

> 3) Der Hoster verwirft die E-Mail, wenn sie bestimmte Absenderdomains hat.

Diese Mail werden nicht "verworfen". Sie kommen im Empfängerpostfach an.
Aber nicht in im Ordner "Inbox", sondern in "Spam", obwohl kein
Spamfilter und keine Posteingangsregel aktiv ist.

> Korrekt so?

Fast. ;-)

--
Robert Riebisch

[Arno Welzel]

Robert Riebisch:

> Arno Welzel wrote:
>
>>> Stopp! Hier liegt ein Missverständnis vor. Nicht Google filtert meine
>>> Mails aus. Der Mailserver meines Hosters packt Mails, die über das
>>> Kontaktformular von meinem Webspace ebenda versendet werden und im From:
>>> ein "@google" haben in den Spam-Ordner meines Postfachs. Selbst wenn der
>>> Spamfilter für dieses Postfach deaktiviert ist.
>>
>> Also nochmal langsam:
>>
>> 1) Du hast ein Kontaktformular, was Eingaben per E-Mail weiterleitet.
>
> Ja.
>
>> 2) Die E-Mail geht *nicht* an den MX der Empfangsadresse, sondern
>> generell an den Mailserver eines Hosters.
>
> Ich bin nicht sicher, wie du das meinst.

So wie es da steht: nicht an den MX der Empfangsadresse. Was ein MX ist,
weißt Du?

Wenn also die Mail an @gmx.de gehen soll, würde sie normalerweise direkt
an den Mailserver von GMX geschickt werden und nicht an deinen Provider.

> Das Formular nutzt, wie in früheren Postings gesagt, die mail()-Funktion
> von PHP. Was die im Hintergrund veranstaltet, weiß ich natürlich nicht.

Die mail()-Funktion von PHP schickt normalerweise direkt an den
Mailserver, dessen Domain in der Empfangsadresse angegeben ist.

> Als *Empfänger* ist eine meiner Adressen meiner Domain bei diesem meinem
> Hoster angegeben.

Also die Mails mit den Formulareingaben sollen nur an DICH gehen? Wozu
dann verschiedene Absenderadressen? Nimm doch einfach deine
Empfängeradresse auch als Absender. Was die Leute im Formular als
Absender eingetragen haben, kannst Du ggf. auch als Reply-To angeben
oder einfach als Teil des Textes, der in der E-Mail übermittelt werden.

>> 3) Der Hoster verwirft die E-Mail, wenn sie bestimmte Absenderdomains hat.
>
> Diese Mail werden nicht "verworfen". Sie kommen im Empfängerpostfach an.
> Aber nicht in im Ordner "Inbox", sondern in "Spam", obwohl kein
> Spamfilter und keine Posteingangsregel aktiv ist.

Wenn kein Spamfilter aktiv wäre, würden sie auch nicht im Spam landen.
Wenn der Host darauf besteht, dass sein Server das nicht macht, dann ist
es wohl dein Mail-Client.

[Robert Riebisch]

Arno Welzel wrote:

>>> 2) Die E-Mail geht *nicht* an den MX der Empfangsadresse, sondern
>>> generell an den Mailserver eines Hosters.
>>
>> Ich bin nicht sicher, wie du das meinst.
>
> So wie es da steht: nicht an den MX der Empfangsadresse. Was ein MX ist,
> weißt Du?

Ja, weiß ich. Sonst würde ich von extern keine Mails auf der besagten
Domain empfangen. :-D

> Wenn also die Mail an @gmx.de gehen soll, würde sie normalerweise direkt
> an den Mailserver von GMX geschickt werden und nicht an deinen Provider.

Hm.

>> Das Formular nutzt, wie in früheren Postings gesagt, die mail()-Funktion
>> von PHP. Was die im Hintergrund veranstaltet, weiß ich natürlich nicht.
>
> Die mail()-Funktion von PHP schickt normalerweise direkt an den
> Mailserver, dessen Domain in der Empfangsadresse angegeben ist.

Die Funktion "spielt" also MTA?
So mit MX-Record angucken, Port zum Zielserver öffnen usw.?

Wirft die PHP das nicht in einen Spool-Ordner auf dem Hostsystem, wo
sich dann eine andere Software um das Übermitteln kümmert?

Ja, ich frag' so dumm, weil ich es wirklich nicht weiß und auch noch
nicht gegoogelt habe.

>> Als *Empfänger* ist eine meiner Adressen meiner Domain bei diesem meinem
>> Hoster angegeben.
>
> Also die Mails mit den Formulareingaben sollen nur an DICH gehen? Wozu

Ja. In dem Falle schon.

Es gibt aber noch ein zweites Formular in einer (nicht von mir selbst
geschriebenen) Forumsoftware, welches auch an mich sendet und zusätzlich
noch eine Kopie an die Adresse, die der Besucher eingegeben hat bzw. an
die Adresse, die bei ihm im Userprofil hinterlegt ist, wenn er dort
eingeloggt ist. (Was ein Schachtelsatz. Ich hoffe, du verstehst es.)

> dann verschiedene Absenderadressen? Nimm doch einfach deine

Na, die (= seine eigene Adresse) gibt doch der Besucher in das Formular ein.

> Empfängeradresse auch als Absender. Was die Leute im Formular als
> Absender eingetragen haben, kannst Du ggf. auch als Reply-To angeben
> oder einfach als Teil des Textes, der in der E-Mail übermittelt werden.

Jenau. Das wäre mittlerweile der Plan.

Wundere mich aber eben, dass das beim alten Hoster 10 Jahre lang
funktioniert hat. Aber es scheint ja auch nicht grundsätzlich total
falsch zu sein, denn das einzige Problem, was nach der ganzen
Fehlersuche übrig ist, ist, dass die Mails in den Spam-Ordner verschoben
werden. Und da kann's schon sein, dass beide Hoster unterschiedliche
Techniken einsetzen.

>> Diese Mail werden nicht "verworfen". Sie kommen im Empfängerpostfach an.
>> Aber nicht in im Ordner "Inbox", sondern in "Spam", obwohl kein
>> Spamfilter und keine Posteingangsregel aktiv ist.
>
> Wenn kein Spamfilter aktiv wäre, würden sie auch nicht im Spam landen.

Das sage ich dem Hoster auch.

> Wenn der Host darauf besteht, dass sein Server das nicht macht, dann ist
> es wohl dein Mail-Client.

Nein, kann ich mir nicht vorstellen, denn mein Mail-Client macht nur
POP3. Und die Nachrichten werden lt. Webmail-Ansicht selbst dann in den
Ordner "Spam" geroutet, während ich nicht per POP3 abrufe. (Ich rufe
immer nur manuell ab.)

Habe eben noch mal mit dem guten alten IMAPSize geschaut. -- Ja, landet
wieder im Spam. (Spamfilter noch mal eingeschaltet.)

In den Kopfzeilen der Testmail steht übrigens u. a.:
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on [entfernt]
X-Spam-Level: *
X-Spam-Status: No, score=1.7 required=7.0 tests=DKIM_ADSP_CUSTOM_MED,
FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,
NML_ADSP_CUSTOM_MED,NO_RELAYS,T_SCC_BODY_TEXT_LINE autolearn=no
autolearn_force=no version=3.4.0

Nun kann eine Software hinsichtlich ihrer Versionsnummer natürlich
lügen, aber aktuell wäre SpamAssissin 3.4.6.
Abgesehen davon, besteht aber bei "X-Spam-Level: *" bzw. "X-Spam-Status:
No" aus meiner Sicht kein Anlass, die Mail in den Spam-Ordner zu werfen.

Schalte ich den Filter ab, fehlen diese Kopfzeilen. Passt.

"Jugend" forscht...
Zieht sich noch mal Stichproben von Nachrichten in Inbox und Spam...

Nachricht enthält im "From:" "@gmail.com" und sie landet *nicht* im Spam:
Authentication-Results: [entfernt];
dmarc=fail (p=NONE sp=QUARANTINE) smtp.from=[entfernt]
header.from=gmail.com

Nachricht enthält im "From:" @googlemail.com" und sie landet im Spam:
Authentication-Results: [entfernt];
dmarc=fail (p=QUARANTINE sp=QUARANTINE) smtp.from=[entfernt]
header.from=googlemail.com

Spotted the difference?


https://dmarcian.com/policy-modes-quarantine-vs-reject/ sagt
"p=quarantine allows email receivers to treat email that fails the DMARC
check as suspicious and files them in a SPAM folder."

Klingt somit für mich plausibel, was da mit den Mails passiert.
Ist die Aussage des Supports also richtig, dass es nicht am Spamfilter
liegt. Es liegt ja am DMARC-Filter. *g*
Die Aussage, es würde an einer von mir eingestellten Mailrule bzw.
meinem Mailclient liegen, ist damit aber auch widerlegt.

--
Robert Riebisch

[Stefan Froehlich]

On Thu, 14 Apr 2022 22:41:31 Robert Riebisch wrote:
> Arno Welzel wrote:
>>> Das Formular nutzt, wie in früheren Postings gesagt, die
>>> mail()-Funktion von PHP. Was die im Hintergrund veranstaltet,
>>> weiß ich natürlich nicht.

>> Die mail()-Funktion von PHP schickt normalerweise direkt an den
>> Mailserver, dessen Domain in der Empfangsadresse angegeben ist.

> Die Funktion "spielt" also MTA?
> So mit MX-Record angucken, Port zum Zielserver öffnen usw.?

AFAIK tut sie das unter Windows; unter Linux verwendet sie idR das
sendmail(1) des Hosts bzw. das, was in der Konfiguration unter
sendmail_path hinterlegt ist. Was dort passiert, kann nur Dein
Hoster wissen - es kann direkt versendet werden, es kann aber auch
(IMO nicht ganz unwahrscheinlich) zum SmartHost des Hosters
weitergeleitet werden.

> Wirft die PHP das nicht in einen Spool-Ordner auf dem Hostsystem,
> wo sich dann eine andere Software um das Übermitteln kümmert?

Beinahe.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - mit dem leisen Wahn sehnender Radieschen.
(Sloganizer)

[Arno Welzel]

Robert Riebisch:

> Arno Welzel wrote:

[...]

>> Die mail()-Funktion von PHP schickt normalerweise direkt an den
>> Mailserver, dessen Domain in der Empfangsadresse angegeben ist.
>
> Die Funktion "spielt" also MTA?
> So mit MX-Record angucken, Port zum Zielserver öffnen usw.?

Das kommt auf die Konfiguration und das Betriebssystem an:

<https://www.php.net/manual/de/function.mail.php>

> Wirft die PHP das nicht in einen Spool-Ordner auf dem Hostsystem, wo
> sich dann eine andere Software um das Übermitteln kümmert?

Nein, nicht zwangsläufig.

[...]

>> Also die Mails mit den Formulareingaben sollen nur an DICH gehen? Wozu
>
> Ja. In dem Falle schon.
>
> Es gibt aber noch ein zweites Formular in einer (nicht von mir selbst
> geschriebenen) Forumsoftware, welches auch an mich sendet und zusätzlich
> noch eine Kopie an die Adresse, die der Besucher eingegeben hat bzw. an
> die Adresse, die bei ihm im Userprofil hinterlegt ist, wenn er dort
> eingeloggt ist. (Was ein Schachtelsatz. Ich hoffe, du verstehst es.)

Für "Kopie an den Absender des Formulars" gilt das, was schon zur
Verwendung von Absenderadressen im Zusammenhang mit SPF und DKIM gesagt
wurde.

[...]

>> Empfängeradresse auch als Absender. Was die Leute im Formular als
>> Absender eingetragen haben, kannst Du ggf. auch als Reply-To angeben
>> oder einfach als Teil des Textes, der in der E-Mail übermittelt werden.
>
> Jenau. Das wäre mittlerweile der Plan.
>
> Wundere mich aber eben, dass das beim alten Hoster 10 Jahre lang
> funktioniert hat. Aber es scheint ja auch nicht grundsätzlich total
> falsch zu sein, denn das einzige Problem, was nach der ganzen
> Fehlersuche übrig ist, ist, dass die Mails in den Spam-Ordner verschoben
> werden. Und da kann's schon sein, dass beide Hoster unterschiedliche
> Techniken einsetzen.

Der neue Hoster hat halt einen Server, der nicht mehr kommentarlos
einfach alles akzeptiert, was man ihm schickt.

[...]

> "Jugend" forscht...
> Zieht sich noch mal Stichproben von Nachrichten in Inbox und Spam...
>
> Nachricht enthält im "From:" "@gmail.com" und sie landet *nicht* im Spam:
> Authentication-Results: [entfernt];
> dmarc=fail (p=NONE sp=QUARANTINE) smtp.from=[entfernt]
> header.from=gmail.com
>
> Nachricht enthält im "From:" @googlemail.com" und sie landet im Spam:
> Authentication-Results: [entfernt];
> dmarc=fail (p=QUARANTINE sp=QUARANTINE) smtp.from=[entfernt]
> header.from=googlemail.com
>
> Spotted the difference?

Ja - gmail.com hat offenbar andere DMARC-Regeln als googlemail.com.

> https://dmarcian.com/policy-modes-quarantine-vs-reject/ sagt
> "p=quarantine allows email receivers to treat email that fails the DMARC
> check as suspicious and files them in a SPAM folder."
>
> Klingt somit für mich plausibel, was da mit den Mails passiert.
> Ist die Aussage des Supports also richtig, dass es nicht am Spamfilter
> liegt. Es liegt ja am DMARC-Filter. *g*
> Die Aussage, es würde an einer von mir eingestellten Mailrule bzw.
> meinem Mailclient liegen, ist damit aber auch widerlegt.

Sofern man die Filterung für Verstöße gegen DMARC nicht selbst
einstellen kann, ja.

[Arno Welzel]

Stefan Froehlich:

> On Thu, 14 Apr 2022 22:41:31 Robert Riebisch wrote:
>> Arno Welzel wrote:
>>>> Das Formular nutzt, wie in früheren Postings gesagt, die
>>>> mail()-Funktion von PHP. Was die im Hintergrund veranstaltet,
>>>> weiß ich natürlich nicht.
>
>>> Die mail()-Funktion von PHP schickt normalerweise direkt an den
>>> Mailserver, dessen Domain in der Empfangsadresse angegeben ist.
>
>> Die Funktion "spielt" also MTA?
>> So mit MX-Record angucken, Port zum Zielserver öffnen usw.?
>
> AFAIK tut sie das unter Windows; unter Linux verwendet sie idR das
> sendmail(1) des Hosts bzw. das, was in der Konfiguration unter
> sendmail_path hinterlegt ist. Was dort passiert, kann nur Dein
> Hoster wissen - es kann direkt versendet werden, es kann aber auch
> (IMO nicht ganz unwahrscheinlich) zum SmartHost des Hosters
> weitergeleitet werden.

Üblicherweise schickt sendmail an den MX des Empfängers und keinen
Smarthost. Aber in der Tat hängt das konkrete Verhalten natürlich davon
ab, wie der Hoster es konfiguriert hat.

[Robert Riebisch]

Arno Welzel wrote:

>> Die Funktion "spielt" also MTA?
>> So mit MX-Record angucken, Port zum Zielserver öffnen usw.?
>
> Das kommt auf die Konfiguration und das Betriebssystem an:
>
> <https://www.php.net/manual/de/function.mail.php>

Ok. Danke.

>> Es gibt aber noch ein zweites Formular in einer (nicht von mir selbst
>> geschriebenen) Forumsoftware, welches auch an mich sendet und zusätzlich
>> noch eine Kopie an die Adresse, die der Besucher eingegeben hat bzw. an
>> die Adresse, die bei ihm im Userprofil hinterlegt ist, wenn er dort
>> eingeloggt ist. (Was ein Schachtelsatz. Ich hoffe, du verstehst es.)
>
> Für "Kopie an den Absender des Formulars" gilt das, was schon zur
> Verwendung von Absenderadressen im Zusammenhang mit SPF und DKIM gesagt
> wurde.

Jep.

>>> Empfängeradresse auch als Absender. Was die Leute im Formular als
>>> Absender eingetragen haben, kannst Du ggf. auch als Reply-To angeben
>>> oder einfach als Teil des Textes, der in der E-Mail übermittelt werden.
>>
>> Jenau. Das wäre mittlerweile der Plan.

Habe ich vorhin für Kontaktskript #1 umgesetzt.
(Und bei der Gelegenheit mal kräftig Ballast entsorgt. -> KISS)

Absenderadresse ('From:') ist jetzt immer '<noreply@[entfernt]>'.
Als Absendername wird aber der Name des Besuchers verwendet.
Der steht dann zusammen mit der Besucheradresse auch in 'Reply-to:'.
(Und 'X-Mailer:' verrät mir, dass die Mail über das Kontaktformular kam.)

>> Wundere mich aber eben, dass das beim alten Hoster 10 Jahre lang
>> funktioniert hat. Aber es scheint ja auch nicht grundsätzlich total
>> falsch zu sein, denn das einzige Problem, was nach der ganzen
>> Fehlersuche übrig ist, ist, dass die Mails in den Spam-Ordner verschoben
>> werden. Und da kann's schon sein, dass beide Hoster unterschiedliche
>> Techniken einsetzen.
>
> Der neue Hoster hat halt einen Server, der nicht mehr kommentarlos
> einfach alles akzeptiert, was man ihm schickt.

Ja, wie plöht. ;-)

>> Nachricht enthält im "From:" "@gmail.com" und sie landet *nicht* im Spam:
>> Authentication-Results: [entfernt];
>> dmarc=fail (p=NONE sp=QUARANTINE) smtp.from=[entfernt]
>> header.from=gmail.com
>>
>> Nachricht enthält im "From:" @googlemail.com" und sie landet im Spam:
>> Authentication-Results: [entfernt];
>> dmarc=fail (p=QUARANTINE sp=QUARANTINE) smtp.from=[entfernt]
>> header.from=googlemail.com
>>
>> Spotted the difference?
>
> Ja - gmail.com hat offenbar andere DMARC-Regeln als googlemail.com.

Jenau.

>> Klingt somit für mich plausibel, was da mit den Mails passiert.
>> Ist die Aussage des Supports also richtig, dass es nicht am Spamfilter
>> liegt. Es liegt ja am DMARC-Filter. *g*
>> Die Aussage, es würde an einer von mir eingestellten Mailrule bzw.
>> meinem Mailclient liegen, ist damit aber auch widerlegt.
>
> Sofern man die Filterung für Verstöße gegen DMARC nicht selbst
> einstellen kann, ja.

Rein aus Interesse: Gibt es (noch bezahlbare) Hoster, wo das geht?
Oder muss man für so etwas selbst nen Server betreiben?

Insgesamt schon mal Dankeschön für deine (eure) Unterstützung. :-)

--
Robert Riebisch

[Arno Welzel]

Robert Riebisch:

> Arno Welzel wrote:
[...]

>> Sofern man die Filterung für Verstöße gegen DMARC nicht selbst
>> einstellen kann, ja.
>
> Rein aus Interesse: Gibt es (noch bezahlbare) Hoster, wo das geht?
> Oder muss man für so etwas selbst nen Server betreiben?

Keine Ahnung - ich betreibe meine Mailserver schon seit über 10 Jahren
selber.