Honda: mail() --> SPAM!

Hallo,

ich habe nun bereits einen ganzen Tag damit verbracht zu recherchieren, was man alles tun kann damit Mails die man per mail(); versendet nicht als Spam klassifiziert werden.

Ergebnis --> ich weiss nun genausowenig wie vorher.

Kennt jemand von Euch ein tutorial oder eine halbwegs übersichtliche Quelle dazu?

Oder kann jemand folgende Fragen beantworten?

* Was ist bei der Server-Konfiguration zu beachten wenn man einen Root Server sein Eigen nennen kann? Wie schaffe ich es bounced mails zu erhalten?

* Mein Provider schreibt z.B. in den Received:-Header von mir versendeter Mails stets meine Kundennr. und seine domain hinein

-->(Received: by kunde1.net.web4.hm (Postfix, from userid 55)id E758D29B004C; Sun, 5 Mar 2006 16:13:27 +0100 (CET))

...ist das schädlich im Bezug auf eine Spam-Klassifizierung beim Empfänger?

* Welche Header muss/soll per mail(); mitgeschickt werden.

Merci für jeglichen Input,
Honda

  1. Moin!

    ich habe nun bereits einen ganzen Tag damit verbracht zu recherchieren, was man alles tun kann damit Mails die man per mail(); versendet nicht als Spam klassifiziert werden.

    Ergebnis --> ich weiss nun genausowenig wie vorher.

    Richtig. Es ist auch nicht deine Aufgabe, dir den Kopf darüber zu zerbrechen, welche Anti-Spam-Maßnahmen die möglichen Empfänger deiner Mails treffen. Wenn die Empfänger deine Mails wollen, kriegen sie sie. Wenn sie sie nicht wollen, werden sie sie filtern.

    Es ist eigentlich nur deine Aufgabe, eine standardkonforme Mail zu erstellen und auf die Reise zu schicken.

    Kennt jemand von Euch ein tutorial oder eine halbwegs übersichtliche Quelle dazu?

    Welche Fragen hast du? Welche Probleme sind konkret aufgetreten? Welche Beobachtungen hast du gemacht?

    Oder kann jemand folgende Fragen beantworten?

    * Was ist bei der Server-Konfiguration zu beachten wenn man einen Root Server sein Eigen nennen kann? Wie schaffe ich es bounced mails zu erhalten?

    Hängt von der Serverkonfiguration ab. mail() übergibt die Mail an den lokalen Mailserver, dieser ist für die weitere Behandlung (Sendeversuch, Warteschlange, Bounces) zuständig. Konfiguriere deinen Mailserver passend, und er wird alles tun, was du von ihm willst. Da du einen Root-Server hast, liegt das in deiner Macht oder genauer: Es ist sogar deine Pflicht.

    * Mein Provider schreibt z.B. in den Received:-Header von mir versendeter Mails stets meine Kundennr. und seine domain hinein

    -->(Received: by kunde1.net.web4.hm (Postfix, from userid 55)id E758D29B004C; Sun, 5 Mar 2006 16:13:27 +0100 (CET))

    Jeder Mailserver auf dem Weg vom Sender zum Empfänger trägt sich in einer Received-Zeile ein. Deine Kundennummer ist in dieser Zeile nicht enthalten, und die Domainangabe ergibt sich daraus, dass du einen Server deines Providers benutzt, für den offenbar als PTR im DNS "kunde1.net.web4.hm" konfiguriert ist.

    Alle diese Angaben sind hinsichtlich der Spam-Klassifikation nur insofern schädlich, als dass sie selbstverständlich einem Inhaltsfilter vorgesetzt werden und, wenn der Empfänger mit ähnlichen Wortfragmenten schon ausreichend belästigt wurde, eventuell aussortiert wird.

    Inhaltsfilter sind nach meiner Auffassung aber komplett Userangelegenheit. Er kann diesen Inhaltsfilter seinem Provider delegieren - das ist aber komplett nicht dein Bereich. Wer deine Mails empfangen will, wird seine Filter anpassen (müssen) - wer nicht, tut's eben nicht.

    * Welche Header muss/soll per mail(); mitgeschickt werden.

    Jeder, der notwendig ist, damit der Mailinhalt korrekt übermittelt wird. Es gibt keinen Header, der garantiert, dass die Mail ankommt. Es gibt keinen Header, der garantiert, dass die Mail in jedem Fall aussortiert wird (obwohl "Subject: VIAGRA cheap and enlarge your penis" die Chancen natürlich erhöht).

    Mailfiltermaßnahmen greifen auf mehreren Ebenen:
    1. Verweigerung der Mail-Annahme mit IP-basierten Blacklisten oder ähnlichem. Das registriert dein lokaler Mailserver und wird einen Bounce generieren.
    2. Annahme der Mail und spätere Aussortierung basierend auf: IP-Blacklisten, Inhaltsfiltern, Absenderfiltern etc. - das kannst du nicht registrieren, und da kannst du auch nicht reagieren. Wenn der Provider des Mailempfängers ohne Benachrichtigung des Mailempfängers oder des Mailsenders Mails verschluckt (also z.B. annimmt und dann löscht), hat der Mailprovider entweder dafür vom Mailempfänger die Erlaubnis gekriegt, oder er hat ein Problem (Mailunterschlagung ist verboten).
    3. Mailfilter durch den Mailclient des Empfängers. Kannst du auch nicht erkennen, ist entweder manuell (Spam sehen und löschen) oder automatisch (Inhaltsfilter, Blacklisten etc.).

    - Sven Rautenberg

    --
    My sssignature, my preciousssss!
    1. Hallo Sven,

      danke für die prompte und ausführliche Antwort!

      Richtig. Es ist auch nicht deine Aufgabe, dir den Kopf darüber zu zerbrechen, welche Anti-Spam-Maßnahmen die möglichen Empfänger deiner Mails treffen. Wenn die Empfänger deine Mails wollen, kriegen sie sie. Wenn sie sie nicht wollen, werden sie sie filtern.

      Nun ja,.. es geht mir primär um die großen Freemailer wie Yahoo, AOL Hotmail & Co. Da ich keine Spam-Mails versende, sondern nur eine Registrierungsbestätigung nach erfolgreicher Anmeldung mit Bestätigungslink, wollen meine Empfänger definitiv diese Email erhalten (sonst können sie nicht einloggen). Nun ist folgendes Problem aufgetreten, dass bei einigen Freemailern u.a. Yahoo dieses Bestätigungs-Email bereits in den Standardeinstellungen als Junk klassifiziert wird und so zu einer Flut an Supportarbeit führt, da sich User beschweren das Email nicht erhalten zu haben (wo es doch im Junk-Fach liegt). D.h. jeder User der eine Yahoo-Adresse angibt erhält dieses Email in seinem Junk-Fach!

      Es ist eigentlich nur deine Aufgabe, eine standardkonforme Mail zu erstellen und auf die Reise zu schicken.

      Genau das ist meine Frage. Ich nehme einmal an, dass ich mit einer standardkonformen Mail bei den Freemailern nicht automatisch als Spam eingestuft werde.

      Welche Fragen hast du? Welche Probleme sind konkret aufgetreten? Welche Beobachtungen hast du gemacht?

      Meine Beobachtungen:

      Ich habe Mails von anderen Diensten (die ähnlichen Inhalt haben und in der Regel von den Freemailern nicht als Spam klassifiziert werden) mit meinen verglichen.

      Fazit1: in den nie als Spam klassifizierten Mails tauchte im Received:-Bereich stets deren Domain gefolgt von einer (offenbar ihrer)IP-Adresse auf.

      z.B.:
      Received: from unknown (HELO nat.openbc.com) ([213.238.59.15])
      envelope-sender mailrobot@openbc.com)
      by spamwall.xvveb.net (qmail-ldap-xweb-1.03) with AES256-SHA encrypted SMTP for user@user.com; 3 Mar 2006 10:14:54 -0000

      meine Mails hingegen enthalten (obwohl ich einen [managed]Root-Server besitze) weder meine Domain noch meine IP in dieser Information.

      Da die A- und MX-Records jedoch auf meine IP deuten, und ich aussschliesslich mit der entsprechenden Domain-Endung versende, wäre es ein eindeutiges Indiz (Domain - IP) dass zumindest der Eigentümer der Domain diese Mails versendet (tendenziell also kein Spam).

      Frage: woher soll der Empfänger nun aber wissen von welcher Domain und welcher IP versandt wurde, und ob die records der Domain auf die IP lauten, wenn hier bei Received die Kennung (Domain) meines Hosters enthalten ist? Daher vermute ich zunächst einmal, dass das hier nicht optimal ist.

      Fazit2: Mails die nicht als Spam klassifiziert werden sind offenbar zumeist mit qmail versandt worden.

      Frage dazu: Ist eine Umstellung auf qmail für mich auf programmierer-und betreiberseite mit erheblichen Umstellungs- und Arbeitsaufwand verbunden? (d.h für die codes die mail(); enthalten)? ... oder kann ich dies einfach bei meinem Hoster beantragen und hab damit keine weiteren Probleme!?

      Jeder Mailserver auf dem Weg vom Sender zum Empfänger trägt sich in einer Received-Zeile ein. Deine Kundennummer ist in dieser Zeile nicht enthalten, und die Domainangabe ergibt sich daraus, dass du einen Server deines Providers benutzt, für den offenbar als PTR im DNS "kunde1.net.web4.hm" konfiguriert ist.

      Was genau meinst Du mit PTR im DNS?

      Jeder, der notwendig ist, damit der Mailinhalt korrekt übermittelt wird. Es gibt keinen Header, der garantiert, dass die Mail ankommt. Es gibt keinen Header, der garantiert, dass die Mail in jedem Fall aussortiert wird (obwohl "Subject: VIAGRA cheap and enlarge your penis" die Chancen natürlich erhöht).

      Es geht mir hier vielmehr um Header wie From:, reply,... etc.
      Gibt es hier keine "Best Practice" welche Header bei mail(); verwendet werden sollten?

      Merci & viele Grüsse,
      Honda

      1. [...]

        D.h. jeder User der eine Yahoo-Adresse angibt erhält dieses Email in seinem Junk-Fach!

        [...]

        Wo ist das Problem? Dann sage das doch einfach Deinen Nutzern! Am besten  aber in der Web-Seite und nicht in der Email ;-)

        1. Hi Michael,

          Wo ist das Problem?

          Das das nun kein Problem sein soll, finde ich nicht. Es ist doch ärgerlich für alle Beteiligten, wenn reguläre Mails in Spamordnern landen. Insofern macht es durchaus Sinn, die Kriterien  zu reflektieren.

          Viele Grüße
          Mathias Bigge

      2. Moin!

        Nun ja,.. es geht mir primär um die großen Freemailer wie Yahoo, AOL Hotmail & Co. Da ich keine Spam-Mails versende, sondern nur eine Registrierungsbestätigung nach erfolgreicher Anmeldung mit Bestätigungslink, wollen meine Empfänger definitiv diese Email erhalten (sonst können sie nicht einloggen). Nun ist folgendes Problem aufgetreten, dass bei einigen Freemailern u.a. Yahoo dieses Bestätigungs-Email bereits in den Standardeinstellungen als Junk klassifiziert wird und so zu einer Flut an Supportarbeit führt, da sich User beschweren das Email nicht erhalten zu haben (wo es doch im Junk-Fach liegt). D.h. jeder User der eine Yahoo-Adresse angibt erhält dieses Email in seinem Junk-Fach!

        Das ist natürlich ärgerlich, aber wie Michael schon vorgeschlagen hat: Den User auf der Webseite drauf hinweisen, dass die Mail auch als Spam klassifiziert werden könnte, sollte schon helfen.

        Das Problem ist: Kurze Bestätigungsmails haben nicht viel Text. Der Text, der enthalten ist, sieht oft so aus, wie der in Spam-Mails (dort gibts auch Links zu URLs mit langen Parametern).

        Genau das ist meine Frage. Ich nehme einmal an, dass ich mit einer standardkonformen Mail bei den Freemailern nicht automatisch als Spam eingestuft werde.

        Doch. Wenn du den Mailtext deinem Mailserver übergibst, regelt der schon automatisch, dass die Mail dem SMTP-Standard entspricht. Dem Standard nicht zu entsprechen hebt vielleicht etwas die Spamhaltigkeit, aber das würde ich nicht als signifikant bezeichnen.

        Fazit1: in den nie als Spam klassifizierten Mails tauchte im Received:-Bereich stets deren Domain gefolgt von einer (offenbar ihrer)IP-Adresse auf.

        z.B.:
        Received: from unknown (HELO nat.openbc.com) ([213.238.59.15])
        envelope-sender mailrobot@openbc.com)
        by spamwall.xvveb.net (qmail-ldap-xweb-1.03) with AES256-SHA encrypted SMTP for user@user.com; 3 Mar 2006 10:14:54 -0000

        Naja, dieser Header ist eigentlich schon eher so ein kleines Negativbeispiel. Der sendende Server hat jedenfalls keinen Reverse-DNS-Eintrag (deshalb steht da "from unknown", und weiter hinten die IP-Adresse in eckigen Klammern). Es hilft aber etwas, so einen Eintrag zu haben. Und wenn der dann auch noch mit der HELO-Angabe übereinstimmt, wäre das auch gut. Man weiß ja nie, welche seltsamen Kriterien manche Mailadmins so anlegen. Wie gesagt: Alles keine Garantie, aber Indizien.

        meine Mails hingegen enthalten (obwohl ich einen [managed]Root-Server besitze) weder meine Domain noch meine IP in dieser Information.

        Den Reverse-DNS-Eintrag solltest du irgendwo bei deinem Provider einrichten können, damit deiner IP ein DNS-Name zugeordnet werden kann, der auf dich schließen läßt.

        Da die A- und MX-Records jedoch auf meine IP deuten, und ich aussschliesslich mit der entsprechenden Domain-Endung versende, wäre es ein eindeutiges Indiz (Domain - IP) dass zumindest der Eigentümer der Domain diese Mails versendet (tendenziell also kein Spam).

        Hm, nö, dem Gedankengang kann ich nicht so ganz folgen. Die A- und MX-Einträge sind für den Versand von Mail von dir weg für keinen anderen Mailserver relevant. Die einzige (allerdings genau betrachtet auch sehr schwache, weil beliebig "fälschbare") Verbindung wäre der Reverse-DNS-Record (das meinte ich mit "PTR"). Der empfangende Mailserver kennt nur die IP des Senders, schaut im DNS nach, welcher Name dazugehört, und schaut dann nach, welche IP zu diesem Namen gehört - wenn wieder die gleiche IP rauskommt, ist der Besitzer der IP offenbar auch der Besitzer der Domain und hat auf beides gleichermaßen Einfluß. Dann geht es nur noch darum: Ist die IP "böse" (d.h. in Blacklisten verzeichnet)? Ist die Domain böse? Ist der Inhalt böse?

        Frage: woher soll der Empfänger nun aber wissen von welcher Domain und welcher IP versandt wurde, und ob die records der Domain auf die IP lauten, wenn hier bei Received die Kennung (Domain) meines Hosters enthalten ist? Daher vermute ich zunächst einmal, dass das hier nicht optimal ist.

        Wie gesagt: Wenn du jetzt mal deine IP rückwärts auflöst, kommt dein Providerdomainname bei raus. Ändere das, wenn möglich.

        Schau auch mal nach, ob deine IP oder das Netzwerk deines Providers in Blacklisten Erwähnung findet.

        Fazit2: Mails die nicht als Spam klassifiziert werden sind offenbar zumeist mit qmail versandt worden.

        Das ist irrelevant. Wirklich. Ich sende mit Postfix, und ich habe keine Probleme.

        Außerdem halte ich qmail für einen Mailserver, den man besser meiden sollte, wenn man es kann. Vom Programmierer gibt es zwar diese tolle "Hat keine Bugs"-Garantie, der Nachteil ist allerdings, dass das Programm im Originalzustand heutzutage nahezu unbrauchbar für die eigene Spamfilterung ist. Will man irgendwas sinnvolles an Funktionalität haben, muß man viel patchen. Da nehme ich dann doch lieber Postfix, das ist einfacher zu konfigurieren und bringt viele sinnvolle Funktionen direkt mit.

        Frage dazu: Ist eine Umstellung auf qmail für mich auf programmierer-und betreiberseite mit erheblichen Umstellungs- und Arbeitsaufwand verbunden? (d.h für die codes die mail(); enthalten)? ... oder kann ich dies einfach bei meinem Hoster beantragen und hab damit keine weiteren Probleme!?

        Was heißt hier "beantragen"? Du hast einen Root-Server, das mußt du gefälligst selbst machen.

        Jeder, der notwendig ist, damit der Mailinhalt korrekt übermittelt wird. Es gibt keinen Header, der garantiert, dass die Mail ankommt. Es gibt keinen Header, der garantiert, dass die Mail in jedem Fall aussortiert wird (obwohl "Subject: VIAGRA cheap and enlarge your penis" die Chancen natürlich erhöht).

        Es geht mir hier vielmehr um Header wie From:, reply,... etc.
        Gibt es hier keine "Best Practice" welche Header bei mail(); verwendet werden sollten?

        Mir ist nichts bekannt. Zwingend ist, dass gewisse Header vorkommen müssen, ansonsten wird's mit dem Ankommen der Mail nichts. Andere Header sind optional. Kein Header ist aufgrund seines Vorkommens böse. Aber Header und Body können aufgrund ihres INHALTS als böse eingestuft werden.

        Und du könntest natürlich auch mal bei Yahoo anklopfen und die drum bitten, dass deine Mails nicht im Spamfilter landen. Vielleicht erreichst du was - dürfte aber erst ab einem gewissen Aufkommen an Mails für die interessant werden, aber es ist grundsätzlich durchaus verhandelbar, als Mailversender auf Whitelisten zu kommen.

        - Sven Rautenberg

        --
        My sssignature, my preciousssss!
  2. Moin!

    ich habe nun bereits einen ganzen Tag damit verbracht zu recherchieren, was man alles tun kann damit Mails die man per mail(); versendet nicht als Spam klassifiziert werden.

    Ganz einfach: man vermeide unter allen Umständen Spam zu versenden.

    MFFG (Mit freundlich- friedfertigem Grinsen)

    fastix®

    --
    Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development