Indy SMTP MultiPart Messages werden als SPAM aussortiert...

[DocE]

Hallo,

wenn ich mit Indy MultiPart eMails verschicke, werden diese zum Beispiel von GMX als SPAM aussortiert. Dies scheint an der Boundary zu liegen:

=_NextPart_2rfkindysadvnqw3nerasdf

also:
Content-Type: multipart/alternative;
boundary="=_NextPart_2rfkindysadvnqw3nerasdf";
charset="ISO-8859-1"

GMX fügt dem Header hinzu:

X-GMX-Antispam: 5 (Score=3.36; GMX_GENUINE_GMX_S MIME_BOUND_RKFINDY MIME_HTML_NO_CHARSET X_LIBRARY MIME_BOUND_NEXTPART)

Da ich es nicht geschafft habe, die Boundary zur Laufzeit mit der TidMessage zu ändern, habe ich versucht die Boundary direkt im Source zu ändern, in der Datei: IdMessageCoderMIME.pas, in der diese Boundarys als CONST deklariert sind.

Allerdings scheint er die Datei nicht neu zu kompilieren. Beim nächsten Versand steht immer noch die alte Boundary in der eMail. Ich habe das gesamte Delphi-Verzeichnis nach dem Text "NextPart" durchsucht und wurde nur in der o.g. Datei fündig.

Hat der Ausdruck {do not localize} evtl. etwas damit zu tun?

const
IndyMIMEBoundary = '=_NextPart_2rfkindysadvnqw3nerasdf'; {do not localize}


Ich weiß an dieser Stelle wirklich nicht mehr weiter! Bin für jegliche Hilfe dankbar.

Vielen Dank!
DocE

[DocE]

Hallo zusammen,

ich habe jetzt eine Lösung gefunden und möchte euch nur kurz informieren. Sie ist zwar etwas umständlich führt aber zu dem gewünschten Ergebnis. Vielleicht kann ich hiermit einigen ebenfalls weiterhelfen. Würde mich über Feedback freuen.

Ich erstelle zunächst eine TIdMessage mit den verschiedenen Parts (Text/HTML/Attachments). Anschließend speichere ich diese Nachricht in einem Stream (SaveToStream) und übergebe Sie einem String. Dieser wird in Header und Body gesplittet. Anschließend werden im Body die Indy Boundarys mit StringReplace durch meine ersetzt. Aus dem Header extrahiere ich den Wert "Content-Type" (HeaderList vorher mit GenerateHeader generieren) und führe ebenfalls ein StringReplace durch.

Der neue Body wird in eine zweite IdMessage eingefügt. Im Header der zweiten Nachricht wird das ersetzte Content-Type gesetzt. Die zweite Nachricht kann jetzt gesendet werden und wird nicht mehr als SPAM aussortiert.


Vielen Dank an alle, die sich Zeit genommen haben, meine Frage zu lesen.

MfG
..DocE

[SirThornberry]

wie du in deinem ersten post bereits geschrieben hast kann man da auch direkt in der indy datei ändern. Um die Änderungen dann auch zu compilieren musst du entweder das indy-package neu compilieren oder die geänderte Datei dem Projekt hinzufügen.

[Flocke]

Zitat aus der Indy-KB (http://www.indyproject.org/KB/spamassasin.htm):

Zitat:

Some filters such as SpamAssassin have other tests they use for filtering E-Mail and a score is generated for a particular message. Administrators then use a given score as a "cut-off" when filtering E-Mail spam. Unfortunately, in the process of filtering E-Mail from certain spamware programs, SpamAssassin is also filtering out E-Mail from any Indy-based program (a false positive).

One test SpamAssasin uses is detecting the pattern in the MIME message part boundary which the Indy code has generated. In Indy 10, we have addressed this by making the boundary more random.

In addition, we have made sure that the from header will always contain a name if the name property is blank. We have also forced the In-Reply-To header to always be generated. This helps reduce the score SpamAssassin assigns. We have recently sent E-Mail and received a Spam Assassin score of 0.

Please keep in mind that these aren't the only test SpamAssasin does. There are some other tests involving the content of the E-Mail, some header values, some blacklists such as MAPS, and other filtering technologies. Some legitimate E-Mail messages can generate false-positives with those tests.

Vielleicht wäre ein Upgrade auf Indy 10 die Lösung?

[DocE]

Hallo,

vielen Dank für eure Antworten.

Da wäre ein Upgrade auf Indy 10 wohl nicht schlecht... Obwohl, dann war ja die ganze Arbeit umsonst :-D

Das mit dem neu Kompilieren habe ich versucht, allerdings ist der "Bearbeiten"-Button unter Komponente/Packages installieren bei Indy deaktiviert. Werde mal versuchen die Datei direkt hinzuzufügen. Sie steht allerdings bereits in der uses Liste. Wird trotzdem nicht kompiliert.


MfG
..DocE

[SirThornberry]

is muss beim package einen "compilieren" - Button geben auf den du klicken kannst.
Und mit "die unit deinem projekt hinzufügen" meinte ich nicht das es einfach in die uses kommen muss sonder du musst die unit über "Project->Add To Project" hinzufügen.

[DocE]

Danke!

Das mit dem Hinzufügen hatte ich verstanden, war nur nen Hinweis mit der uses Liste.

Den Fehler habe ich schon gefunden. Die DCUs liegen im LIB Verzeichnis, die PAS-Dateien im Source Verzeichnis und werden anscheinend nicht kompiliert. Ein umbenennen der DCUs bringt den Fehler "(...).dcu nicht gefunden.".

Die Lösung: Die geänderte .pas Datei einrach in das LIB Verzeichnis kopieren. Da hätte ich wirklich schon eher drauf kommen können.

Vielen Dank!

MfG
..DocE

[SirThornberry]

wie in dem anderne posting bereits geschrieben kann man auch das source-verzeichnis zu den Pfaden hinzufügen: "Tools->Envirement Options->Library" dort hinter "Library Path:" auf den Button "..." klicken und den Pfad hinzufügen.

[DocE]

Zitat:

Zitat von SirThornberry

wie in dem anderne posting bereits geschrieben kann man auch das source-verzeichnis zu den Pfaden hinzufügen: "Tools->Envirement Options->Library" dort hinter "Library Path:" auf den Button "..." klicken und den Pfad hinzufügen.

Ich war der Meinung, dies sei bereits der Fall. Denn wenn man mit STRG auf die TIdIrgendwas klickt, dann öffnet sich immer eine .pas aus diesem Pfad. Dann konnte ich ja nicht davon ausgehen, dass die nicht erneut kompiliert werden.

MfG
..DocE

[TPeterT]

Hallo!

Wegen diesem Eintrag nochmals:

IndyMIMEBoundary = '=_NextPart_2rfkindysadvnqw3nerasdf'; {do not localize}

Gegen was soll das getauscht oder abgeändert werden, damit das Spam-Problem behoben ist?

Danke und liebe Grüsse
Peter