Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailreader > #1437 > unrolled thread

[PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken

Back to article view | Back to de.comm.software.mailreader

Contents

  [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-01 21:42 +0200
    Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-01 23:20 +0200
      Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-02 19:27 +0200
        Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-03 10:35 +0200
          Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-05 18:58 +0200
            Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Marco Moock <mm+solani@dorfdsl.de> - 2025-05-05 19:53 +0200
              Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-06 00:39 +0200
                Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Thomas Hochstein <thh@thh.name> - 2025-05-06 07:40 +0200
                  Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-07 19:26 +0200
                    Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Thomas Hochstein <thh@thh.name> - 2025-05-09 19:45 +0200
                      Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Marco Moock <mm+solani@dorfdsl.de> - 2025-05-09 20:36 +0200
                Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Marco Moock <mm+solani@dorfdsl.de> - 2025-05-06 16:55 +0200
                  Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-07 19:31 +0200
                    Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Marco Moock <mm+solani@dorfdsl.de> - 2025-05-07 19:39 +0200
        Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-03 12:03 +0200
          Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-03 13:32 +0200
          Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-05 19:22 +0200
            Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-05 20:02 +0200
              Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-06 00:45 +0200
                Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Thomas Hochstein <thh@thh.name> - 2025-05-06 07:43 +0200
                  Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-07 19:47 +0200
                    Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Thomas Hochstein <thh@thh.name> - 2025-05-09 19:45 +0200
                      Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-11 23:56 +0200
                        Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Thomas Hochstein <thh@thh.name> - 2025-05-12 07:45 +0200
                Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Marco Moock <mm+solani@dorfdsl.de> - 2025-05-06 16:57 +0200
                  Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-07 19:37 +0200
                    Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Marco Moock <mm+solani@dorfdsl.de> - 2025-05-07 19:42 +0200
                    Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-08 18:49 +0200
                    Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Thomas Hochstein <thh@thh.name> - 2025-05-09 19:45 +0200
                      Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-09 21:01 +0200
                        Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Thomas Hochstein <thh@thh.name> - 2025-05-09 21:20 +0200
                          Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Marco Moock <mm+solani@dorfdsl.de> - 2025-05-09 21:32 +0200
                          Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-10 09:18 +0200
    Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Marco Moock <mm+solani@dorfdsl.de> - 2025-05-02 10:23 +0200
      Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-02 21:17 +0200
        Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken Marco Moock <mm+solani@dorfdsl.de> - 2025-05-02 21:31 +0200
          Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-03 12:10 +0200
            Re: [PMail] SMTP-Fehler beim Versuch, Mails per Verteiler zu verschicken "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-05-05 19:26 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1464

Thomas Hochstein wrote:
> Chr. Maercker schrieb:
>> Wenn das der Fehler wäre, hätten die
>> Verteiler zu keiner Zeit funktioniert. Und im von Dir gesnippten
>> SMTP-Dialog ist deutlich zu sehen, dass die einzelnen Mailadressen *aus*
>> der Liste an den Server gesendet werden. Und sie werden allesamt mit OK
>> quittiert!

> Und nach DATA kommt die Mail, nämlich die Headerzeilen, eine Leerzeile und
> dann der Body. Und den prüft GMX. Und wenn dort im Header "To:
> @Family.PML" steht, ist das falsch und würde den Fehler erklären.

Allerdings erst seit einigen Jahren, vohrher ging das ja. Im übrigen
habe ich gelegentlich Tests mit
	telnet <mailserver>:25 <Input.txt
gemacht, mit einer Input.txt folgenden Inhalts:

EHLO <name>
MAIL FROM:<local@maildomain.de>
RCPT TO:<name@uni-dingelstaedt.de>
DATA
Subject: SMTP-Test
Test via TCP:25
Ist Spamming wirklich so einfach?
.

Funktionierte lange Jahre. Zugestellt wurde an die Adresse(n) nach RCPT
TO:, Absender wurde aus FROM übernommen.

> Es liegt auch nahe, dass irgendein anderer Mailserver irgendwann anders
> irgendwo anders die Header nicht geprüft hat.

Das ist inzwischen meine Vermutung. Verwendet wird der falsche
Adresseintrag aber bis heute nicht, oder?

-- 


	CU	Chr. Maercker.

[toc] | [prev] | [next] | [standalone]

#1468

Chr. Maercker schrieb:

> Thomas Hochstein wrote:
>> Und nach DATA kommt die Mail, nämlich die Headerzeilen, eine Leerzeile und
>> dann der Body. Und den prüft GMX. Und wenn dort im Header "To:
>> @Family.PML" steht, ist das falsch und würde den Fehler erklären.
> 
> Allerdings erst seit einigen Jahren, vohrher ging das ja.

Möglich, wenn das auch aus Deinem OP nicht hervorgeht; dort schriebst Du
nämlich:
| Die gleichen Listen wurden bis 2022 via TCP:25 an einem internen
| Mail-Relay verwendet, ohne dass es solche Probleme gab.

Daraus ergibt sich noch nicht, dass es bis 2022 auch bei GMX ging.

> Im übrigen
> habe ich gelegentlich Tests mit
> 	telnet <mailserver>:25 <Input.txt
> gemacht, mit einer Input.txt folgenden Inhalts:
> 
> EHLO <name>
> MAIL FROM:<local@maildomain.de>
> RCPT TO:<name@uni-dingelstaedt.de>
> DATA
> Subject: SMTP-Test
> Test via TCP:25
> Ist Spamming wirklich so einfach?
> .
> 
> Funktionierte lange Jahre. Zugestellt wurde an die Adresse(n) nach RCPT
> TO:, Absender wurde aus FROM übernommen.

Ja, und? Da ist ja nun auch gerade kein syntaktisch ungültiger Header
drin.

>> Es liegt auch nahe, dass irgendein anderer Mailserver irgendwann anders
>> irgendwo anders die Header nicht geprüft hat.
> 
> Das ist inzwischen meine Vermutung. Verwendet wird der falsche
> Adresseintrag aber bis heute nicht, oder?

Wie meinen?

-thh

[toc] | [prev] | [next] | [standalone]

#1474

Thomas Hochstein wrote:
>>> Es liegt auch nahe, dass irgendein anderer Mailserver irgendwann anders
>>> irgendwo anders die Header nicht geprüft hat.
>>
>> Das ist inzwischen meine Vermutung. Verwendet wird der falsche
>> Adresseintrag aber bis heute nicht, oder?

> Wie meinen?

Was im Header steht, dient der Darstellung beim Empfänger, wird aber
nicht für Transport/Zustellung verwendet. Dort und nur dort trägt PMail
ja die ungültige "Adresse" ein, richtig zugestellt wurden die Mails
trotzdem.
-- 


	CU	Chr. Maercker.

[toc] | [prev] | [next] | [standalone]

#1475

Chr. Maercker schrieb:

> Thomas Hochstein wrote:
>>> Das ist inzwischen meine Vermutung. Verwendet wird der falsche
>>> Adresseintrag aber bis heute nicht, oder?
> 
> > Wie meinen?
> 
> Was im Header steht, dient der Darstellung beim Empfänger, wird aber
> nicht für Transport/Zustellung verwendet.

Ah. Ja, richtig. (Anders nur in Ausnahmefällen, wenn aus den Headern die
Zustellinformationen generiert werden sollen.)

> Dort und nur dort trägt PMail
> ja die ungültige "Adresse" ein, richtig zugestellt wurden die Mails
> trotzdem.

Yep.

-thh

[toc] | [prev] | [next] | [standalone]

#1458

Am 06.05.2025 00:45 Uhr schrieb Chr. Maercker:

> Wenn im SMTP-Dialog
> 	RCPT TO: @Family.PML
> erscheinen würde, hättest Du recht. Wenn das der Fehler wäre, hätten
> die Verteiler zu keiner Zeit funktioniert. Und im von Dir gesnippten
> SMTP-Dialog ist deutlich zu sehen, dass die einzelnen Mailadressen
> *aus* der Liste an den Server gesendet werden. Und sie werden
> allesamt mit OK quittiert!

Erst kommt RCPT TO, das ist hier ok. Dann kommt DATA und darin From:,
To: etc. Steht da Bockmist drin, kann die Mail erst nach Ende des
Kommandos (CRLF.CRLF) abgelehnt werden. Das passiert hier.

-- 
Gruß
Marco

Spam und Werbung bitte an
1746485128ichwillgesperrtwerden@nirvana.admins.ws

[toc] | [prev] | [next] | [standalone]

#1461

Marco Moock wrote:
> Am 06.05.2025 00:45 Uhr schrieb Chr. Maercker:
> 
>> Wenn im SMTP-Dialog
>> 	RCPT TO: @Family.PML
>> erscheinen würde, hättest Du recht. Wenn das der Fehler wäre, hätten
>> die Verteiler zu keiner Zeit funktioniert. Und im von Dir gesnippten
>> SMTP-Dialog ist deutlich zu sehen, dass die einzelnen Mailadressen
>> *aus* der Liste an den Server gesendet werden. Und sie werden
>> allesamt mit OK quittiert!

> Erst kommt RCPT TO, das ist hier ok. Dann kommt DATA und darin From:,
> To: etc. Steht da Bockmist drin, kann die Mail erst nach Ende des
> Kommandos (CRLF.CRLF) abgelehnt werden. Das passiert hier.

Daraus ergeben sich für mich zwei Fragen:
1. Wozu sind die FROM und RCPT TOs gut, wenn beides anschließend im DATA
Block wiederholt wird?

2. Haben native SMTP-Server früher solche Fehler ignoriert oder warum
tritt der Fehler erst jetzt und via TCP:587 auf? Sie müssten seinerzeit
die FROMs und RCPT TOs weitergeleitet haben und den Dateinamen im Header
ignoriert, sonst wären diese Mails niemals zugestellt worden.
-- 


	CU	Chr. Maercker.

[toc] | [prev] | [next] | [standalone]

#1463

Am 07.05.2025 19:37 Uhr schrieb Chr. Maercker:

> Marco Moock wrote:
> > Am 06.05.2025 00:45 Uhr schrieb Chr. Maercker:
> >   
> >> Wenn im SMTP-Dialog
> >> 	RCPT TO: @Family.PML
> >> erscheinen würde, hättest Du recht. Wenn das der Fehler wäre,
> >> hätten die Verteiler zu keiner Zeit funktioniert. Und im von Dir
> >> gesnippten SMTP-Dialog ist deutlich zu sehen, dass die einzelnen
> >> Mailadressen *aus* der Liste an den Server gesendet werden. Und
> >> sie werden allesamt mit OK quittiert!  
> 
> > Erst kommt RCPT TO, das ist hier ok. Dann kommt DATA und darin
> > From:, To: etc. Steht da Bockmist drin, kann die Mail erst nach
> > Ende des Kommandos (CRLF.CRLF) abgelehnt werden. Das passiert hier.
> >  
> 
> Daraus ergeben sich für mich zwei Fragen:
> 1. Wozu sind die FROM und RCPT TOs gut, wenn beides anschließend im
> DATA Block wiederholt wird?

FROM und RCPT für das eigentliche Routing, From: und To: sind in der
Mail selbst sichtbar. Es gibt (eher gab) neben SMTP noch andere
Protokolle für die Übertragung, der User soll aber immer das gleiche
sehen.

> 2. Haben native SMTP-Server früher solche Fehler ignoriert oder warum
> tritt der Fehler erst jetzt und via TCP:587 auf? Sie müssten
> seinerzeit die FROMs und RCPT TOs weitergeleitet haben und den
> Dateinamen im Header ignoriert, sonst wären diese Mails niemals
> zugestellt worden.

Nicht jeder Provider hat da die gleichen harten "Regeln". Lange, lange
wurden und werden nicht RFC-konforme Mails durchgelassen. Bei der
Submission kann man aber restriktiver sein und dafür sorgen, dass die
User RFC-konforme Clients nutzen.

-- 
Gruß
Marco

Spam und Werbung bitte an
1746639470ichwillgesperrtwerden@nirvana.admins.ws

[toc] | [prev] | [next] | [standalone]

#1465

On 2025-05-07 17:37, Chr. Maercker <Zweistein@gmx-topmail.de> wrote:
> Marco Moock wrote:
>> Am 06.05.2025 00:45 Uhr schrieb Chr. Maercker:
>>> Wenn im SMTP-Dialog
>>> 	RCPT TO: @Family.PML
>>> erscheinen würde, hättest Du recht. Wenn das der Fehler wäre, hätten
>>> die Verteiler zu keiner Zeit funktioniert. Und im von Dir gesnippten
>>> SMTP-Dialog ist deutlich zu sehen, dass die einzelnen Mailadressen
>>> *aus* der Liste an den Server gesendet werden. Und sie werden
>>> allesamt mit OK quittiert!
>
>> Erst kommt RCPT TO, das ist hier ok. Dann kommt DATA und darin From:,
>> To: etc. Steht da Bockmist drin, kann die Mail erst nach Ende des
>> Kommandos (CRLF.CRLF) abgelehnt werden. Das passiert hier.
>
> Daraus ergeben sich für mich zwei Fragen:
> 1. Wozu sind die FROM und RCPT TOs gut, wenn beides anschließend im DATA
> Block wiederholt wird?

Werden sie ja nicht. Envelope (also MAIL FROM und RCPT TO) und Header
können sich durchaus unterscheiden und tun das auch oft.

Angenommen Du schreibst eine Mail

| From: <Zweistein@gmx-topmail.de>
| To: foo@example.com, bar@beispiel.at
| Bcc: baz@example.com
| Subject: Test
| 
| 123 Test 123

Dann wird Dein Mailer wahrscheinlich (es gibt andere Möglichkeiten)
folgendes an den Submission-Server schicken:

| MAIL FROM:<Zweistein@gmx-topmail.de>
| RCPT TO:<foo@example.com>
| RCPT TO:<bar@beispiel.at>
| RCPT TO:<baz@example.com>
| DATA
| From: <Zweistein@gmx-topmail.de>
| To: foo@example.com, bar@beispiel.at
| Subject: Test
| 
| 123 Test 123
| .

Du bemerkst, dass die Adresse baz@example.com jetzt nur im Envelope
vorkommt, nicht im Header. Die soll ja "blind" sein, also für die
Empfänger nicht sichtbar.

Der Submission-Server wird jetzt bemerken, dass er die Mail an zwei
verschiedene Domains (und damit vermutlich verschiedene MX weiterleiten
soll, also schickt er an den MX von example.com:

| MAIL FROM:<Zweistein@gmx-topmail.de>
| RCPT TO:<foo@example.com>
| RCPT TO:<baz@example.com>
| DATA
| Received: ...
| From: <Zweistein@gmx-topmail.de>
| To: foo@example.com, bar@beispiel.at
| Subject: Test
| 
| 123 Test 123
| .

und an den von beispiel.at:

| MAIL FROM:<Zweistein@gmx-topmail.de>
| RCPT TO:<bar@beispiel.at>
| DATA
| Received: ...
| From: <Zweistein@gmx-topmail.de>
| To: foo@example.com, bar@beispiel.at
| Subject: Test
| 
| 123 Test 123
| .

Jeder Empfänger-MTA bekommt nur die RCPT-Zeilen, die für ihn relevant
sind. Der Header bleibt aber für beide gleich.

Insbesondere die Mail an example.com ist interessant: Da kommt im
Envelope eine Adresse vor, die im Header nicht vorkommt und im Header
eine, die im Envelope nicht vorkommt ...

Ein MTA kann auch eine Empfänger-Adresse durch ein oder mehrer ersetzen
(z.B. bei einer Weiterleitung) und auch die Absender-Adresse ändern
(z.B. bei VERP, um für jeden Empfänger eine eindeutige Absender-Adresse
zu bekommen, um Bounces zuordnen zu können).


>
> 2. Haben native SMTP-Server früher solche Fehler ignoriert

Großteils ja. Eigentlich muss ein MTA in den DATA-Block gar nicht
reinschauen, er kann ihn einfach 1:1 kopieren (er muss nur eine
Received-Zeile davorpappen). Ein Submission-Server sollte zumindest
sicherstellen, dass gewisse Pflicht-Header vorhanden sind (das habe ich
oben weggelassen) und die gegebenfalls ergänzen. Das haben auch früher
schon viele MTAs gemacht. Aber dafür reicht ein sehr rudimentärer
Parser.

> oder warum tritt der Fehler erst jetzt und via TCP:587 auf? Sie
> müssten seinerzeit die FROMs und RCPT TOs weitergeleitet haben und den
> Dateinamen im Header ignoriert, sonst wären diese Mails niemals
> zugestellt worden.

Der To-Header interessiert einen MTA im Allgemeinen tatsächlich nicht.
Aber es gibt einige Gründe, warum insbesondere ein Submission-Server den
trotzdem parsen könnte. Z.B. um sicherzustellen, dass die Mail
syntaktisch korrekt ist, um Spam-Filter zu aktualisieren (wenn Du
jemandem eine Mail schickst, willst Du vemutlich die Antwort lesen), um
Adressfälschung durch die eigenen User zu verhindern, vielleicht für
DKIM (auch wenn ich im RFC auf die Schnelle keine Notwendigkeit dafür
sehe), etc.

        hjp

[toc] | [prev] | [next] | [standalone]

#1466

Chr. Maercker schrieb:

> 1. Wozu sind die FROM und RCPT TOs gut, wenn beides anschließend im DATA
> Block wiederholt wird?

Das wird es nicht.

Im SMTP-Dialog wird die Zustellung geregelt. Danach kommt die Mail (Header
und Body); die ist dem Mailserver grundsätzlich egal, die schaufelt er
einfach so, wie sie ist, weiter (und zwar an die per RCPT TO übermittelten
Adressaten). Die Angaben in MAIL FROM und RCPT TO müssen daher auch
überhaupt nichts mit den Angaben im Header zu tun haben.

Man _kann_ aber natürlich auch die Header prüfen. Das macht man u.a. zur
Spamfilterung. Und da ist es ein ganz niedrigschwelliger Ansatz, zunächst
einmal Mails mit kaputten Headern abzulehnen, denn das mag zwar selten
sein, aber das sind überproportionel Spammer; und wenn nicht, ist die
Ablehnung einer defekten Mail kein großer Verlust.

> 2. Haben native SMTP-Server früher solche Fehler ignoriert

Möglich. Ob und wie auf Angaben im Header (oder Body) gefiltert wird,
entscheidet jeder Serverbetreiber für sich selbst. Das betrifft DKIM, das
betrifft Spamfilter wie SpamAssassin, und das betrifft auch die Ablehnung
RFC-widriger Mails.

> oder warum tritt der Fehler erst jetzt und via TCP:587 auf? Sie müssten seinerzeit
> die FROMs und RCPT TOs weitergeleitet haben und den Dateinamen im Header
> ignoriert, sonst wären diese Mails niemals zugestellt worden.

Das mag alles sein, ist aber doch für die im Raum stehende Frage egal.

Die war nämlich:
| Merkwürdig ist, dass die Meldungen stets erst nach der DATA-Anweisung
| kommen d.h. wenn die Verteilerliste bereits abgearbeitet ist. So als
| wäre der Body fehlerhaft.

Nein, nicht der Body, sondern der Header.

Und:
| Ist PegaMail nicht mehr 100% RFC-konform, was verschlüsseltes SMTP
| betrifft?

Nein. Es hat nichts mit "verschlüsseltem SMTP" zu tun, und offensichtlich
ist "PegaMail" nicht RFC-konform. (Und mutmaßlich ist das früher schlicht
nicht aufgefallen.)

-thh

[toc] | [prev] | [next] | [standalone]

#1470

Thomas Hochstein <thh@thh.name> wrote:
>und wenn nicht, ist die
>Ablehnung einer defekten Mail kein großer Verlust.

Wenn ich mir angucke, wie grotesk defekt manche Mails aus sog.
"Enterprise-Tools" sind, würde ich diese Aussage abhängig von den
Kommiunikationspartnern nicht mehr unbedingt unterschreiben wollen.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#1471

Marc Haber schrieb:

> Thomas Hochstein <thh@thh.name> wrote:
>> und wenn nicht, ist die
>> Ablehnung einer defekten Mail kein großer Verlust.
> 
> Wenn ich mir angucke, wie grotesk defekt manche Mails aus sog.
> "Enterprise-Tools" sind, würde ich diese Aussage abhängig von den
> Kommiunikationspartnern nicht mehr unbedingt unterschreiben wollen.

Wenn diese Enterprise-Tools ihre Mails nicht mehr loswerden - darum ging
es ja; um den Sender, nicht den Empfänger -, ist das Problem genau an der
richtigen Stelle.

[toc] | [prev] | [next] | [standalone]

#1472

Am 09.05.2025 21:20 Uhr schrieb Thomas Hochstein:

> Marc Haber schrieb:
> 
> > Thomas Hochstein <thh@thh.name> wrote:  
> >> und wenn nicht, ist die
> >> Ablehnung einer defekten Mail kein großer Verlust.  
> > 
> > Wenn ich mir angucke, wie grotesk defekt manche Mails aus sog.
> > "Enterprise-Tools" sind, würde ich diese Aussage abhängig von den
> > Kommiunikationspartnern nicht mehr unbedingt unterschreiben wollen.
> >  
> 
> Wenn diese Enterprise-Tools ihre Mails nicht mehr loswerden - darum
> ging es ja; um den Sender, nicht den Empfänger -, ist das Problem
> genau an der richtigen Stelle.

Ich kann dem nur zustimmen. Leider ist den Entwicklern und Entscheidern
bei den Entwicklerfirmen sowas in der Regel egal.

-- 
Gruß
Marco

Spam und Werbung bitte an
1746818453ichwillgesperrtwerden@nirvana.admins.ws

[toc] | [prev] | [next] | [standalone]

#1473

Thomas Hochstein <thh@thh.name> wrote:
>Marc Haber schrieb:
>
>> Thomas Hochstein <thh@thh.name> wrote:
>>> und wenn nicht, ist die
>>> Ablehnung einer defekten Mail kein großer Verlust.
>> 
>> Wenn ich mir angucke, wie grotesk defekt manche Mails aus sog.
>> "Enterprise-Tools" sind, würde ich diese Aussage abhängig von den
>> Kommiunikationspartnern nicht mehr unbedingt unterschreiben wollen.
>
>Wenn diese Enterprise-Tools ihre Mails nicht mehr loswerden - darum ging
>es ja; um den Sender, nicht den Empfänger -, ist das Problem genau an der
>richtigen Stelle.

Das ist den Betreibern dieser Enterprise-Tools in aller Regel egal,
sie erwarten dass sich der Empfänger anpasst.

-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#1439

Am 01.05.2025 21:42 Uhr schrieb Chr. Maercker:

> Natives SMTP (TCP:25) hat heute kaum noch ein seriöser Mailserver
> offen. An sich OK, leider hilft bei verschlüsseltem SMTP Wireshark
> nicht weiter und ich kann nicht testen, was via TCP:25 abgeht.

Claws Mail bietet ein Protokoll mit Netzwerklog. Alternativ mal per
swaks manuell senden.

> Merkwürdig ist, dass die Meldungen stets erst nach der DATA-Anweisung
> kommen d.h. wenn die Verteilerliste bereits abgearbeitet ist. So als
> wäre der Body fehlerhaft.

Je nach Konfiguration (Milter & Co.) kann das gut sein.


-- 
Gruß
Marco

Spam und Werbung bitte an
1746128523ichwillgesperrtwerden@nirvana.admins.ws

[toc] | [prev] | [next] | [standalone]

#1441

Marco Moock wrote:
> Claws Mail bietet ein Protokoll mit Netzwerklog. Alternativ mal per
> swaks manuell senden.

PMail liefert die letzten ca. 20 Zeilen des SMTP-Dialogs. Ist bei Claws
zu erkennen, was nach der DATA-Anweisung an den Mailserver geschickt
wird? Dort scheint ja das Problem zu sein, FROM und TO vorher werden
allesamt mit OK quittiert.

Als nächstes versuche ich, ob mir Mails ohne STARTLS abgenommen werden.
Dann kann evtl. Wireshark was zutage bringen.

-- 


	CU	Chr. Maercker.

[toc] | [prev] | [next] | [standalone]

#1442

Am 02.05.2025 21:17 Uhr schrieb Chr. Maercker:

> Marco Moock wrote:
> > Claws Mail bietet ein Protokoll mit Netzwerklog. Alternativ mal per
> > swaks manuell senden.  
> 
> PMail liefert die letzten ca. 20 Zeilen des SMTP-Dialogs. Ist bei
> Claws zu erkennen, was nach der DATA-Anweisung an den Mailserver
> geschickt wird? Dort scheint ja das Problem zu sein, FROM und TO
> vorher werden allesamt mit OK quittiert.

Leider nein. Ob man das einstellen kann, weiß ich nicht, ggf. mal in
der Mailingliste nachfragen.

> Als nächstes versuche ich, ob mir Mails ohne STARTLS abgenommen
> werden. Dann kann evtl. Wireshark was zutage bringen.

Nimm doch swaks, das zeigt alles an und kann auch TLS/STARTTLS nutzen.

-- 
Gruß
Marco

Spam und Werbung bitte an
1746213470ichwillgesperrtwerden@nirvana.admins.ws

[toc] | [prev] | [next] | [standalone]

#1446

On 2025-05-02 19:31, Marco Moock <mm+solani@dorfdsl.de> wrote:
> Am 02.05.2025 21:17 Uhr schrieb Chr. Maercker:
>> Marco Moock wrote:
>> > Claws Mail bietet ein Protokoll mit Netzwerklog. Alternativ mal per
>> > swaks manuell senden.  
>> 
>> PMail liefert die letzten ca. 20 Zeilen des SMTP-Dialogs.

Da ist wahrscheinlich der Header nicht mehr vollständig enthalten,
selbst wenn die Mail ist sehr kurz ist :-(.

>> Ist bei Claws zu erkennen, was nach der DATA-Anweisung an den
>> Mailserver geschickt wird? Dort scheint ja das Problem zu sein, FROM
>> und TO vorher werden allesamt mit OK quittiert.
>
> Leider nein. Ob man das einstellen kann, weiß ich nicht, ggf. mal in
> der Mailingliste nachfragen.
>
>> Als nächstes versuche ich, ob mir Mails ohne STARTLS abgenommen
>> werden. Dann kann evtl. Wireshark was zutage bringen.
>
> Nimm doch swaks, das zeigt alles an und kann auch TLS/STARTTLS nutzen.

Da das Problem mit großer Wahrscheinlichkeit in den von PegaMail
generierten Headern liegt, wird das wenig nützen, denn Swaks produziert
ziemlich sicher nicht exakt die gleichen Header wie PegaMail. Man kann
zwar mit Swaks auch eine Mail aus einem File verschicken, aber dazu muss
man die Mail erst mal in einem File haben. Wenn das der Fall ist, kann
man sich das File auch direkt ansehen, um herauszufinden, wo der Fehler
liegt (die Fehlermeldung kennen wir ja bereits, die wird bei einem
erfolgreichen Experiment mit Swaks genau die gleiche sein).

        hjp

[toc] | [prev] | [next] | [standalone]

#1450

Peter J. Holzer wrote:
[PMail liefert die letzten ca. 20 Zeilen des SMTP-Dialogs.]

> Da ist wahrscheinlich der Header nicht mehr vollständig enthalten,
> selbst wenn die Mail ist sehr kurz ist :-(.

Bei nur einer Adresse in der Liste ist der Log offenbar vollständig.

> Da das Problem mit großer Wahrscheinlichkeit in den von PegaMail
> generierten Headern liegt, wird das wenig nützen, denn Swaks produziert
> ziemlich sicher nicht exakt die gleichen Header wie PegaMail. 

FULL ACK, was ich brauche, ist ein Tracing Tool, was die Details der
DATA-Anweisung zeigt. Ohne SSL wäre das Wireshark.
-- 


	CU	Chr. Maercker.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.comm.software.mailreader

csiph-web