Mit dem Pre versendete Mails werden immer als Spam markiert

Jo was schreibt dein Pre in die erste Zeile? Was hast du wo eingestellt?

Ich geb ja zu das mir das zwar sofort aufgefallen ist als ich die erste Mails über meinen Server
geschickt habe, Probleme hatte ich selber bisher aber nicht, auch kein Negatives Feedback.
Selbst verwende ich aber obige Spam Filter nicht, weshalb mir das nur "Unangenehm" aufgefallen
ist, aber vielleicht bin ich da auch zu pingelig

Auch fehlen mir für verlässliche Angaben die Referenzen, der Pre ist leider bald mehr ausserhäusig,
so das ich hier nun wirklich nicht so viel Erfahrung sammeln konnte.
Wenn ich aber höre das das bei einigen hier im Spamfiler landet macht mir das Angst ;), und das
bei einem Business Handy.

Ich hab Ursprünglich angenohmmen das das bei allen so ist, weil mir bis jetzt da auch noch keine
Einstellmöglichkeit bei Clients untergekommen ist. Normal verwenden die ja auch Maschienenname
oder Adresse, hab ich Vielleicht bei den Systemeinstellungen Irgendwo nichts eingetragen?

Deshalb die Frage, wie meldet sich deiner und Vielleicht erkennst du an der Meldung wo du was
eingestellt hast

Ich mein, die Amis verwenden doch auch Spamfilter oder?

Mein Chatter hat das jedenfalls nie gemacht, Vesamail hab ich zu wenig verwendet.

Diesen falschen Received-Header kann man leider auch nicht so einfach dem Mailprogramm abgewöhnen, da das wohl der Mailservice macht und den kann man nicht so leicht patchen.

wenn du nach wie vor zuviele Fehltreffer haben solltest:
schau dir die Lösung von Spamfence (eleven) an. Diese ganze statistische Bewerterei von Mails ist letztlich nur "mäßig geill"
entweder es rutscht was durch, oder wichtige Mails werden aussortiert. Das passiert bei spamfence nicht. Als Privatnutzer kannste kostenlos in den Genuss dieses Dienstes kommen. Nur ein Tipp

Schliesendlich ist das ein Lapsus von Palm, ich hoffe mal das das noch gefixt wird,
ansonsten wenn ich meinen wieder habe werd ich mich mal auf die suche machen,
vielleicht ist es ja nur ein Label. Wenn die das aber hardcodiert in Ihrer App haben
sollten die das fixen.

Wenn der Client bei der Anmeldung sich offensichtlich mit einem gefakten Namen
meldet ist das nicht in Ordnung.

Als ich das das erstemal vor ca. 4 Wochen gesehen habe, hat mich das nur gestört,
im laufe dieses Fadens ist mir aber bewußt geworden das da durchaus Probleme
entstehen können. Und das Filtern, überprüfen von Received Einträgen auf ihre
schlüssigkeit ist für mich nachvollziebar durchaus eine brauchbare Methode um
Spam auszufiltern.

Vesamail macht das übrigends auch nicht, nur um mal im gleichen Haus zu bleiben.
Received: from COM ([188.46.36.120])
warum also plötzlich der Pre? Klar, kein SMTP prüft den zugang anhand dieser
Angabe, weshalb aus sicht des Programmieres es egal ist was da steht, ein
leeres HELO geht aber auch nicht.

Aber warum macht das nur bei einem Spamfilter probleme? Und erst jetzt, liege
ich falsch? Ich weiß bis Heute nicht warum mein Pre (Simulator) das macht und
andere scheinbar nicht. Und was steht da bei den anderen?
Mein echter hat das Übrigends auch gemacht, dabei ist mir das ja erst aufgefallen.

Ich mein wozu sonst gibt es den Regeln?

RFC2821:
4.1.4 Order of Commands
[...]
    The SMTP client MUST, if possible, ensure that the domain parameter
                    ^^^^^^^^^^^^^^^^^    
    to the EHLO command is a valid principal host name (not a CNAME or MX
                             ^^^^^^^^^^^^^^^^^^^^^^^^^    
    name) for its host.  If this is not possible (e.g., when the client's
    address is dynamically assigned and the client does not have an
    obvious name), an address literal SHOULD be substituted for the
    domain name and supplemental information provided that will assist in
    identifying the client.

wenn sich keiner drum kümert?

Zitat von opaaladin

Wenn der Client bei der Anmeldung sich offensichtlich mit einem gefakten Namen
meldet ist das nicht in Ordnung.
.
.
.
Vesamail macht das übrigends auch nicht, nur um mal im gleichen Haus zu bleiben.
Received: from COM ([188.46.36.120])
warum also plötzlich der Pre? Klar, kein SMTP prüft den zugang anhand dieser
Angabe, weshalb aus sicht des Programmieres es egal ist was da steht, ein
leeres HELO geht aber auch nicht.

Aber warum macht das nur bei einem Spamfilter probleme? Und erst jetzt, liege
ich falsch? Ich weiß bis Heute nicht warum mein Pre (Simulator) das macht und
andere scheinbar nicht. Und was steht da bei den anderen?
Mein echter hat das Übrigends auch gemacht, dabei ist mir das ja erst aufgefallen.

Ich mein wozu sonst gibt es den Regeln?

Code

RFC2821:
4.1.4 Order of Commands
[...]
    The SMTP client MUST, if possible, ensure that the domain parameter
                    ^^^^^^^^^^^^^^^^^    
    to the EHLO command is a valid principal host name (not a CNAME or MX
                             ^^^^^^^^^^^^^^^^^^^^^^^^^    
    name) for its host.  If this is not possible (e.g., when the client's
    address is dynamically assigned and the client does not have an
    obvious name), an address literal SHOULD be substituted for the
    domain name and supplemental information provided that will assist in
    identifying the client.

Alles anzeigen

wenn sich keiner drum kümert?

Alles anzeigen

Mein Pre macht das auch. Im "Received" wird ww.palm.com [$dynamische-ip] ngezeigt. Habe das eben getestet. Der Spamassasin auf dem Host dem ich das geschickt habe hat das nicht moniert.
Ich habe Testweise noch eine Mail von meinem grossen Rechner geschickt und sehe dort:

Received: from cassiopeia.localnet ($dynamische-ip)

Das ist zwar mein Hostname, aber nicht der FQDN. Es kann also irgendwas übertragen werden scheint mir.
Das Problem tauchte hier im Ursprungspost wohl auf weil der lokale Spamfilter zu scharf eingerichtet war.

Gruß, sui

Hab grad mal eine Mail an den eurosupport geschieben, mal sehen was die mir antworten.
Ich zitier mich mal selbst:
Vesamail macht das übrigends auch nicht, nur um mal im gleichen Haus zu bleiben.
Received: from COM ([188.46.36.120])

ich lach mich scheckig, Vesamail hat das wohl auch schon gemacht, aber wegen einem
Bug(?) nur das COM abgeliefert ;), Möglich währs.

Natürlich kann man den Filter weniger scharf stellen, aber hallo, wo kommen wir den
da hin.

Received: from cassiopeia.localnet ($dynamische-ip)
Kann ja nicht aufgelöst werden, also Fantasiename gegen dynamische IP, kein Problem.

Aber um einen Brief als Beispiel zu nehmen, da lasse ich doch auch den Absender weg
oder schreib vom Nikolaus drauf und verwende nicht eine falsche existierende Adresse,
es sei den ich hab böses im Schilde.

So, heute habe ich von Palm endlich mal eine Antwort bekommen:
--
Wir haben Ihren Fall rekonstruieren können und haben das gleiche Phänomen festgestellt wie Sie. Dieser Eintrag erscheint tatsächlich durch den Pre versandte Email. Zu hinterfragen wäre ob dies der Grund ist, dass die Emails im Spamfilter landen. Unsere Tests haben gezeigt, dass lediglich Outlook diese Mails als Spam deklariert. Egal von welchem Account die Mail verschickt wird. Sobald Outlook diese Mail zieht wird Sie als Spam gewertet. Dies könnte am Eintrag "www.palm.com" liegen.

Nun ja uns ist auf jeden Fall unbekannt woher dieses kommt. Dieser Fall wurde nun an England weiter geleitet und wird baldmöglichst bearbeitet. Sobald wir was wissen lassen geben wir Ihnen bescheid. Wenn Sie zwischenzeitlich nach dem Status fragen wollen geben Sie bitte die Fallnummer an.

Dieser Eintrag ist durch aus Fragwürdig und wird nun näher untersucht warum er überhaupt da ist.

Wie sind Ihre Erfahrungen? Unter welchen Bedienungen landen Ihre Mails im Spam?

Fuer weitere Fragen stehen wir Ihnen jederzeit gerne zur Verfuegung.

--

es passiert also doch was
Wenn also die Betroffenen sich dazu selbst einlassen wollen, meine Fallnummer lautet 1-51748535551

Nun die ersten Antworten gingen schon in die Richtung "klicken Sie hier, erfragen Sie die Zugangsdaten ..."
Erst als ich dann etwas säuerlich geantwortet habe das ich anhand der Antworten erkennen kann das man
sich nicht mal die Mühe macht die Mail zu lesen kam heute diese Antwort ;), mit einer Entschuldigung am
Anfang, welche ich aber weggelassen habe (hat ja nichts mit der Geschichte zu tun).

Zumindest zeigt mir das "fragwürdig" das man das Problem erkannt hat und da die ja jetzt festgestellt
haben das z.b. Outlook die Mail egal von welchen Account als Spam markiert wird da mit Sicherheit
eine Änderung vorgenohmmen.

Edit: ich frage mich aber imernoch warum das erst jetzt aufgefallen ist, bestimmte Spamfilter markieren
die Mails, Outlook markiert die Mail. Ist das bei den Amis normal das die Mails als Spam markiert werden

Bei uns stuft es die Borderware, die vor unserem Exchange hängt, immer als Spam ein. Aber wegen "Content" angeblich.

Zitat von opaaladin

ich frage mich aber imernoch warum das erst jetzt aufgefallen ist, bestimmte Spamfilter markieren
die Mails

Normal:
1. getestet wird beim Kunden
2. Firmen, die im Vertrieb hauptsächlich auf Emailkommunikation setzen, halten eine restriktive Spam-Policy oft nicht durch. Die Endnutzer wollen nicht dauernd im Quarantäne-Ordner nachgucken oder Whitelists pflegen. Reine Internet-Versandgeschäfte stellen dafür einen dedizierten Spam-Admin ein, der nichts anderes tut als die zentrale Spam-Quarantäne manuell auszuwerten und Whitelists zu bauen.

EDIT: möglicherweise ist der WinMob-Treo noch das Standard-Diensthandy bei Palm. Keiner bemerkt den Bug.

Bei 1.4 scheint sich diesbezüglich was getan zu haben.
Bisher konnte ich nie eine Mail an meine Firmenadresse schicken, die wurde immer vom globalen Spamfilter auf unserem Mailserver abgefangen. Jetzt hab ichs nach dem Update nochmal probiert und die Mail kam problemlos an.

kann ich so leider nicht bestätigen, habe es gerade nach dem Update getestet,
mails werden immer noch als http://www.palm.com versendet.

Auch mit dem Zwischenupdate 1.4.1 hat sich an der Header-Problematik nichts geändert...

Nachdem letztens wieder eine Mail vom Pre an meinen Dienstaccount im Spam-Filter gelandet ist, habe ich mal nach einer Lösung auf Seiten meines Mailservers gesucht. Muss beim Mailversand ja irgendwie möglich sein, noch was am Header zu drehen und das geht auch.

Bei mir ist die Situation so, dass ich meine Mails alle über einen daheim gehosteten Postfix Server verschicke. Da ich da nur eine dynamische IP habe und daher bei einem direkten Versand wohl ständig in den Spamfiltern landen würde, gehen die Mails von meinem heimischen Postfix-Server über einen weiteren Server bei meinem Provider, den ich für 0,50 Euro/Monat gemietet habe.

Nach kurzer Suche habe ich hier den zielführenden Hinweis gefunden.

Ich habe auf meinem Debian Lenny System noch das Paket postfix-pcre installiert und dann in der Datei /etc/postfix/main.cf die folgende Zeiel angehängt:

header_checks = pcre:/etc/postfix/headers.pcre

In der dort angegebene Datei habe ich dann Folgendes eingetragen:

/^Received:.*www\.palm\.com/ IGNORE

Die paar Zeilen haben anscheinend Erfolg, auch wenn ich gerade nicht auf der Arbeit testen kann. Unten habe ich mal die Mail-Header von 'ner Mail angehängt, die ich an mich selbst geschickt habe.

Vorher:

Return-Path: <ich@meine-domain.de>
X-Original-To: ich@meine-domain.de
Delivered-To: ich@meine-domain.de
Received: from www.palm.com (unknown [89.204.xxx.xxx])
	by mail.meine-domain.de (Postfix) with ESMTPSA id 0141E19C414
	for <ich@meine-domain.de>; Sun, 18 Jul 2010 11:51:11 +0000 (UTC)
Date: Sun, 18 Jul 2010 13:53:16 +0200
From: "Mein Name" <ich@meine-domain.de>
To: "Mein Name" <ich@meine-domain.de>
Reply-To: "Mein Name" <ich@meine-domain.de>
Subject: Test
X-Mailer: Palm webOS v1.0.1
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary=Alternative__boundary__1279454003120
Message-Id: <20100718115112.0141E19C414@mail.meine-domain.de>

Nachher:

Return-Path: <ich@meine-domain.de>
X-Original-To: ich@meine-domain.de
Delivered-To: ich@meine-domain.de
Date: Sun, 18 Jul 2010 13:55:52 +0200
From: "Mein Name" <ich@meine-domain.de>
To: "Mein Name" <ich@meine-domain.de>
Reply-To: "Mein Name" <ich@meine-domain.de>
Subject: Test 2
X-Mailer: Palm webOS v1.0.1
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary=Alternative__boundary__1279454156461
Message-Id: <20100718115345.AB79F19CAA8@mail.meine-domain.de>

Der Ansatz von Dorowan hat mich auf eine Idee gebracht, die jetzt aber bei der Ausführung hinkt:

ich habe einen eigene root-Webserver, über den ich mittels qmail meine Mails vom PalmPre über pop/smtp in die Welt versende. Bei qmail gibt es, ähnlich wie bei postfix, u.U. eine Möglichkeit den Mailheader vor dem Versand zu manipulieren, also auch ggf. die unnötige Header Zeile mit dem "Received: unknown (HELO http://www.palm.com) xxx.xxx.xxx.xxx)" zu entfernen/abzuändern. Die manpages zu qmail-inject (= qmail-inject reads a mail message from its standard input, adds appropriate information to the message header, and invokes - preprocess and send a mail message qmail-queue to send the message to one or more recipients.) sprengen entweder mein Verständnis oder, wie ich befürchte, es gibt garkeinen Parameter zum "filtern" der Headerzeile unter qmail-inject

Hat jemand mit dieser Thematik bereit Erfahrungen gesammelt, ist qmail/qmail-inject erfahren oder hat Langeweile sich mit mir den Kopf zu zerbrechen ?

P.S.: postfix statt qmail einzusetzen kommt für mich nicht in Frage! :-p Und so lange auf eine Regung von Palm zu warten, das ganze mit irgendeinem in der Ferne liegenden Update zu fixen (den Bug habe ich bereits mehrfach bei Palm gemeldet!), erscheint mir zu müßig - selbst ist der Mann

Nur bringt dieses selfmade nur Leuten mit eigenem Mailserver etwas, also einem verschwindend geringen Teil.
Der Großteil verwendet Firmenserver oder Accounts beim Provider und diesen ist dieser Weg verschlossen,
weshalb da Palm schon in die Pötte kommen sollte.
Habe das Thema jetzt aber auch eine Weile auf sich beruhen lassen da andere Probleme, werde aber jetzt mal
mein Ticket nachfragen, schliesslich wurde mir ja bestätigt das dieses Verhalten zumindest "zweifelhaft" ist.

ElDuderino sieht so aus als ob qmail-inject nur Info Zeilen zufügen kann, aber nicht verändern, was man in
unserem Fall müsste.