Spam über CC-Listen

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Spam über CC-Listen

Peter Buettner
Hallo zusammen!

Ich habe eher ungewöhnliche Fragen, die ein wenig über das Thema postfix
hinausgehen.

Ein Endanwender sendet E-Mails  mit langen CC-Listen und großen
Anhängen. Er verwendet WIN 10 und Outlook aus Office 2010. Virenscanner
ist bitdefender.

In den Logs ist zu erkennen, daß einige Empfänger dieser Mail mit
Greylisting den Empfang verzögern. Es ist weiterhin zu sehen, daß
Verzögerungsmitteilungen an den Endanwender gehen. Alle 2 Minuten werden
die CC's erneut mit der Mail beglückt. Nach dem Abbruch einer solchen
Spamtirade zeigte pflogsum, daß an die CC's 36 mal  zugestellt wurde.

Meine Fragen:

- Ist es eine undokumentierte Funktionalität von postfix, daß die
Mail in diesem Szenario 36 mal zugestellt wurde?

- Ist es eine undokumentierte Funktionalität von Outlook, welches 36 mal
eingeliefert hat?

- Kann bitdefender etwas damit zu tun haben ?

- Oder hat der Endanwender tatsächlich 36 mal auf Senden gedrückt?

- Gibt es in Postfix eine Möglichkeit, solchen Spam zu erkennen oder
zumindest die Anzahl der CC's zu begrenzen?

Peter Büttner
AlsterCom e.K.
Reply | Threaded
Open this post in threaded view
|

Re: Spam über CC-Listen

Ralf Hildebrandt
* Peter Buettner <[hidden email]>:
> Hallo zusammen!
>
> Ich habe eher ungewöhnliche Fragen, die ein wenig über das Thema postfix
> hinausgehen.
>
> Ein Endanwender sendet E-Mails  mit langen CC-Listen und großen
> Anhängen.

Vorsicht: Lange Cc: Listen könnten abmahnbar sein:
https://www.e-recht24.de/news/datenschutz/7652-cc-an-alle-e-mails-datenschutzbehoerde-verhaengt-bussgeld-wegen-offenem-e-mail-verteiler.html

> Er verwendet WIN 10 und Outlook aus Office 2010. Virenscanner ist
> bitdefender.
>
> In den Logs ist zu erkennen, daß einige Empfänger dieser Mail mit
> Greylisting den Empfang verzögern.

Völlig normal.

> Es ist weiterhin zu sehen, daß Verzögerungsmitteilungen an den
> Endanwender gehen.

Die sendet dann aber Postfix?

> Alle 2 Minuten werden die CC's erneut mit der Mail beglückt. Nach dem
> Abbruch einer solchen Spamtirade zeigte pflogsum, daß an die CC's 36
> mal zugestellt wurde.

Also an alle Empfänger? Alle zwei Minuten ist ja auch etwas seltsam,
Postfix läßt ja bei Fehlern immer mehr Zeit zwischen zwei Versuchen.
Vielleicht ruft Outlook alle 2 Minuten Mail ab und führt Regeln aus?

> Meine Fragen:
>
> - Ist es eine undokumentierte Funktionalität von postfix, daß die
> Mail in diesem Szenario 36 mal zugestellt wurde?

Ohne Logs schwer zu sagen.

> - Ist es eine undokumentierte Funktionalität von Outlook, welches 36 mal eingeliefert hat?

Manche nennen sowas Fehler. Aber die Software ist 8 Jahre alt, da kann
schonmal das eine oder andere falsch sein.

> - Kann bitdefender etwas damit zu tun haben ?

Könnte, aber: Ohne Logs schwer zu sagen.
 
> - Oder hat der Endanwender tatsächlich 36 mal auf Senden gedrückt?

Das kann man selbst MIT Logs nicht wirklich erkennen. Aber so blöde
sind benutzer eigentlich nicht. 2-3 mal, aber nicht 36 mal.
 
> - Gibt es in Postfix eine Möglichkeit, solchen Spam zu erkennen oder
> zumindest die Anzahl der CC's zu begrenzen?

Nicht in Postfix direkt; man könnte was mit headerchecks zaubern:


/^(To|CC):(.*@){10}/ HOLD
zum Beispiel

--
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  [hidden email] | https://www.charite.de
           
Reply | Threaded
Open this post in threaded view
|

Re: Spam über CC-Listen

Peter Buettner
Vielen Dank für die schnelle Antwort.

Am 01.11.18 um 12:59 schrieb Ralf Hildebrandt:

> * Peter Buettner <[hidden email]>:
>> Hallo zusammen!
>>
>> Ich habe eher ungewöhnliche Fragen, die ein wenig über das Thema postfix
>> hinausgehen.
>>
>> Ein Endanwender sendet E-Mails  mit langen CC-Listen und großen
>> Anhängen.
>
> Vorsicht: Lange Cc: Listen könnten abmahnbar sein:
> https://www.e-recht24.de/news/datenschutz/7652-cc-an-alle-e-mails-datenschutzbehoerde-verhaengt-bussgeld-wegen-offenem-e-mail-verteiler.html
endanwender mit
Das umgeht der Endanwender mit "To: [hidden email]"

>> Er verwendet WIN 10 und Outlook aus Office 2010. Virenscanner ist
>> bitdefender.
>>
>> In den Logs ist zu erkennen, daß einige Empfänger dieser Mail mit
>> Greylisting den Empfang verzögern.
>
> Völlig normal.
>
>> Es ist weiterhin zu sehen, daß Verzögerungsmitteilungen an den
>> Endanwender gehen.
>
> Die sendet dann aber Postfix?

Genau.

>> Alle 2 Minuten werden die CC's erneut mit der Mail beglückt. Nach dem
>> Abbruch einer solchen Spamtirade zeigte pflogsum, daß an die CC's 36
>> mal zugestellt wurde.
>
> Also an alle Empfänger? Alle zwei Minuten ist ja auch etwas seltsam,
> Postfix läßt ja bei Fehlern immer mehr Zeit zwischen zwei Versuchen.
> Vielleicht ruft Outlook alle 2 Minuten Mail ab und führt Regeln aus?

2 Minuten durchscnittlich. Unterschiedlich zwischen 1-3 minuten


>> Meine Fragen:
>>
>> - Ist es eine undokumentierte Funktionalität von postfix, daß die
>> Mail in diesem Szenario 36 mal zugestellt wurde?
>
> Ohne Logs schwer zu sagen.
>

Es dauert noch ein Weile, das Logfile zu anonymisieren. Schicke ich dann.

>> - Ist es eine undokumentierte Funktionalität von Outlook, welches 36 mal eingeliefert hat?
>
> Manche nennen sowas Fehler. Aber die Software ist 8 Jahre alt, da kann
> schonmal das eine oder andere falsch sein.
>
>> - Kann bitdefender etwas damit zu tun haben ?
>
> Könnte, aber: Ohne Logs schwer zu sagen.
>  
>> - Oder hat der Endanwender tatsächlich 36 mal auf Senden gedrückt?
>
> Das kann man selbst MIT Logs nicht wirklich erkennen. Aber so blöde
> sind benutzer eigentlich nicht. 2-3 mal, aber nicht 36 mal.

Mein Endanwender kann sehr stur und beharrlich sein

>  
>> - Gibt es in Postfix eine Möglichkeit, solchen Spam zu erkennen oder
>> zumindest die Anzahl der CC's zu begrenzen?
>
> Nicht in Postfix direkt; man könnte was mit headerchecks zaubern:
>
> Vielleicht klärt sich das Ganze ja auch auf und es sind keine Maßnahmen
nötig.


> /^(To|CC):(.*@){10}/ HOLD
> zum Beispiel
>

Peter Büttner
AlsterCom e.K.
Reply | Threaded
Open this post in threaded view
|

Re: [ext] Re: Spam über CC-Listen

Ralf Hildebrandt
* Peter Buettner <[hidden email]>:

> > Vorsicht: Lange Cc: Listen könnten abmahnbar sein:
> > https://www.e-recht24.de/news/datenschutz/7652-cc-an-alle-e-mails-datenschutzbehoerde-verhaengt-bussgeld-wegen-offenem-e-mail-verteiler.html

> Das umgeht der Endanwender mit "To: [hidden email]"

Dann hat er aber keine CC: Liste, sondern eine Bcc: Liste.

> >> Alle 2 Minuten werden die CC's erneut mit der Mail beglückt. Nach dem
> >> Abbruch einer solchen Spamtirade zeigte pflogsum, daß an die CC's 36
> >> mal zugestellt wurde.
> >
> > Also an alle Empfänger? Alle zwei Minuten ist ja auch etwas seltsam,
> > Postfix läßt ja bei Fehlern immer mehr Zeit zwischen zwei Versuchen.
> > Vielleicht ruft Outlook alle 2 Minuten Mail ab und führt Regeln aus?
>
> 2 Minuten durchscnittlich. Unterschiedlich zwischen 1-3 minuten

Man müsste bei den Mails genau die Header ansehen (insbes. Message-id
und QueueID) und so feststellen, welches System diese Mails verdoppelt.

Möglichkeiten:

* Outlook schickt immer wieder - dann sollte man immer neue QueueIDs
  sehen und eigentlich auch message-ids

* ein Zwischensystem sendet die Mails immer wieder (z.B. weil dort ein
  Virenscanner mit der Mail nicht klar kommt) - dann sollte in den
  Header die die VORGELAGERTEN Systeme angelegt haben keine Änderung zu
  sehn sein. Die anderen Header würden dann variieren.

--
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  [hidden email] | https://www.charite.de
           
Reply | Threaded
Open this post in threaded view
|

Re: [ext] Re: Spam über CC-Listen

Peter Buettner
wie versprochen, die Auswertung des Logfiles. Von den 36 Einlieferungen
nur die esten sechs.

Weil der Server von Rcpt1 keine Transportverschlüsselung unterstützt,
bekommt der Endanwender, ich habe ihn mal Rainer genannt, noch eine
Benachrichtigung, daß an Rcpt1 nicht verschlüsselt geliefert werden kann
und die Mail vom Server gelöscht wurde.

Die Zeitstempel sind sehr merkwürdig. Es wird schon die nächste Mail
eingeliefert, bevor qmgr angefangen hat zu arbeiten. Evt. habe ich auch
etwas von der zeitlichen Abfolge der Verarbeitung falsch verstanden.

Ich glaube nicht, daß Outlook von sich aus den Absender und die CC-Liste
ändert. Der Endanwender hat Postfächer für zwei Domains.

Peter Büttner
AlsterCom e.K.


Oct 27 00:17:32 nge postfix/smtps/smtpd[3393]: F38FC1201131:
client=pentiv.net.a
Oct 27 00:17:39 nge postfix/cleanup[3385]: F38FC1201131:
message-id=<007c01d46d7
Oct 27 00:19:36 nge postfix/qmgr[14998]: F38FC1201131: from=<Rainer@Domain1
Oct 27 00:19:36 nge postfix/encrypted/smtp[3434]: F38FC1201131: to=<Rcpt1@bt
Oct 27 00:19:36 nge postfix/encrypted/smtp[3435]: F38FC1201131: host
eu-smtp-inb
Oct 27 00:19:37 nge postfix/encrypted/smtp[3435]: F38FC1201131: to=<Rcpt2
Oct 27 00:19:38 nge postfix/encrypted/smtp[3443]: F38FC1201131:
to=<undisclosed@
Oct 27 00:19:39 nge postfix/encrypted/smtp[3439]: F38FC1201131: to=<Rcpt3
Oct 27 00:19:40 nge postfix/encrypted/smtp[3444]: F38FC1201131: to=<Rcpt4
Oct 27 00:19:41 nge postfix/encrypted/smtp[3442]: F38FC1201131: to=<Rcpt5
Oct 27 00:19:41 nge postfix/encrypted/smtp[3442]: F38FC1201131: to=<Rcpt6
Oct 27 00:19:41 nge postfix/encrypted/smtp[3437]: F38FC1201131: to=<Rcpt7
Oct 27 00:19:43 nge postfix/encrypted/smtp[3436]: F38FC1201131: to=<Rcpt8
Oct 27 00:19:43 nge postfix/encrypted/smtp[3436]: F38FC1201131: to=<Rcpt9
Oct 27 00:19:43 nge postfix/encrypted/smtp[3436]: F38FC1201131: to=<Rcpt10
Oct 27 00:19:44 nge postfix/encrypted/smtp[3441]: F38FC1201131: to=<Rcpt11>,
Oct 27 00:19:45 nge postfix/encrypted/smtp[3446]: F38FC1201131: to=<Rcpt12
Oct 27 00:19:46 nge postfix/encrypted/smtp[3440]: F38FC1201131: to=<Rcpt13
Oct 27 00:19:54 nge postfix/encrypted/smtp[3445]: F38FC1201131: to=<Rcpt14
Oct 27 00:20:06 nge postfix/encrypted/smtp[3438]: F38FC1201131: to=<Rcpt15
Oct 27 00:20:06 nge postfix/bounce[3450]: F38FC1201131: sender
non-delivery noti
Oct 27 00:20:07 nge postfix/bounce[3447]: F38FC1201131: sender delay
notificatio
Oct 27 00:21:01 nge postfix/postsuper[3476]: F38FC1201131: removed


Oct 27 00:19:23 nge postfix/smtps/smtpd[3420]: CF8A412013D5:
client=pentiv.net.a
Oct 27 00:19:31 nge postfix/cleanup[3428]: CF8A412013D5:
message-id=<008f01d46d7
Oct 27 00:21:34 nge postfix/qmgr[14998]: CF8A412013D5: from=<Rainer@Domain1
Oct 27 00:21:34 nge postfix/encrypted/smtp[3438]: CF8A412013D5: to=<Rcpt1@bt
Oct 27 00:21:36 nge postfix/encrypted/smtp[3493]: CF8A412013D5:
to=<undisclosed@
Oct 27 00:21:37 nge postfix/encrypted/smtp[3492]: CF8A412013D5: to=<Rcpt5
Oct 27 00:21:37 nge postfix/encrypted/smtp[3492]: CF8A412013D5: to=<Rcpt6
Oct 27 00:21:39 nge postfix/encrypted/smtp[3487]: CF8A412013D5: to=<Rcpt7
Oct 27 00:21:40 nge postfix/encrypted/smtp[3489]: CF8A412013D5: to=<Rcpt3
Oct 27 00:21:41 nge postfix/encrypted/smtp[3486]: CF8A412013D5: to=<Rcpt8
Oct 27 00:21:41 nge postfix/encrypted/smtp[3486]: CF8A412013D5: to=<Rcpt9
Oct 27 00:21:41 nge postfix/encrypted/smtp[3486]: CF8A412013D5: to=<Rcpt10
Oct 27 00:21:41 nge postfix/encrypted/smtp[3494]: CF8A412013D5: to=<Rcpt4
Oct 27 00:21:42 nge postfix/encrypted/smtp[3491]: CF8A412013D5: to=<Rcpt11>,
Oct 27 00:21:44 nge postfix/encrypted/smtp[3496]: CF8A412013D5: to=<Rcpt12
Oct 27 00:21:51 nge postfix/encrypted/smtp[3485]: CF8A412013D5: to=<Rcpt2
Oct 27 00:21:57 nge postfix/encrypted/smtp[3495]: CF8A412013D5: to=<Rcpt14
Oct 27 00:22:00 nge postfix/encrypted/smtp[3488]: CF8A412013D5: to=<Rcpt15
Oct 27 00:22:05 nge postfix/encrypted/smtp[3490]: CF8A412013D5: to=<Rcpt13
Oct 27 00:22:05 nge postfix/bounce[3450]: CF8A412013D5: sender
non-delivery noti
Oct 27 00:22:05 nge postfix/bounce[3447]: CF8A412013D5: sender delay
notificatio
Oct 27 00:23:01 nge postfix/postsuper[3526]: CF8A412013D5: removed


Oct 27 00:21:12 nge postfix/smtps/smtpd[3393]: 56C6A1201131:
client=pentiv.net.a
Oct 27 00:21:19 nge postfix/cleanup[3385]: 56C6A1201131:
message-id=<009501d46d7
Oct 27 00:23:14 nge postfix/qmgr[14998]: 56C6A1201131: from=<Rainer@Domain1
Oct 27 00:23:14 nge postfix/encrypted/smtp[3493]: 56C6A1201131: to=<Rcpt1@bt
Oct 27 00:23:17 nge postfix/encrypted/smtp[3488]: 56C6A1201131:
to=<undisclosed@
Oct 27 00:23:17 nge postfix/encrypted/smtp[3495]: 56C6A1201131: to=<Rcpt4
Oct 27 00:23:20 nge postfix/encrypted/smtp[3494]: 56C6A1201131: to=<Rcpt5
Oct 27 00:23:20 nge postfix/encrypted/smtp[3494]: 56C6A1201131: to=<Rcpt6
Oct 27 00:23:20 nge postfix/encrypted/smtp[3489]: 56C6A1201131: to=<Rcpt3
Oct 27 00:23:21 nge postfix/encrypted/smtp[3496]: 56C6A1201131: to=<Rcpt7
Oct 27 00:23:23 nge postfix/encrypted/smtp[3486]: 56C6A1201131: to=<Rcpt11>,
Oct 27 00:23:23 nge postfix/encrypted/smtp[3487]: 56C6A1201131: to=<Rcpt8
Oct 27 00:23:23 nge postfix/encrypted/smtp[3487]: 56C6A1201131: to=<Rcpt9
Oct 27 00:23:23 nge postfix/encrypted/smtp[3487]: 56C6A1201131: to=<Rcpt10
Oct 27 00:23:24 nge postfix/encrypted/smtp[3492]: 56C6A1201131: to=<Rcpt2
Oct 27 00:23:25 nge postfix/encrypted/smtp[3533]: 56C6A1201131: to=<Rcpt12
Oct 27 00:23:26 nge postfix/encrypted/smtp[3490]: 56C6A1201131: to=<Rcpt15
Oct 27 00:23:41 nge postfix/encrypted/smtp[3485]: 56C6A1201131: to=<Rcpt14
Oct 27 00:23:44 nge postfix/encrypted/smtp[3491]: 56C6A1201131: to=<Rcpt13
Oct 27 00:23:44 nge postfix/bounce[3450]: 56C6A1201131: sender
non-delivery noti
Oct 27 00:23:44 nge postfix/bounce[3447]: 56C6A1201131: sender delay
notificatio
Oct 27 00:25:01 nge postfix/postsuper[3571]: 56C6A1201131: removed


Oct 27 00:23:52 nge postfix/smtps/smtpd[3543]: 3BDCC12013D5:
client=pentiv.net.a
Oct 27 00:23:56 nge postfix/cleanup[3426]: 3BDCC12013D5:
message-id=<00a101d46d7
Oct 27 00:23:58 nge postfix/qmgr[14998]: 3BDCC12013D5: from=<rainer@Domain2
Oct 27 00:23:59 nge postfix/encrypted/smtp[3487]: 3BDCC12013D5: to=<Rcpt3
Oct 27 00:23:59 nge postfix/encrypted/smtp[3485]: 3BDCC12013D5: to=<Rcpt4
Oct 27 00:23:59 nge postfix/encrypted/smtp[3488]: 3BDCC12013D5: to=<Rcpt9
Oct 27 00:23:59 nge postfix/encrypted/smtp[3494]: 3BDCC12013D5: to=<Rcpt7
Oct 27 00:23:59 nge postfix/encrypted/smtp[3493]: 3BDCC12013D5: to=<raoul.w
Oct 27 00:24:00 nge postfix/encrypted/smtp[3486]: 3BDCC12013D5: to=<Rcpt12
Oct 27 00:24:01 nge postfix/encrypted/smtp[3533]: 3BDCC12013D5:
to=<undisclosed@
Oct 27 00:24:02 nge postfix/encrypted/smtp[3492]: 3BDCC12013D5: to=<Rcpt14
Oct 27 00:24:02 nge postfix/bounce[3450]: 3BDCC12013D5: sender
non-delivery noti
Oct 27 00:24:02 nge postfix/qmgr[14998]: 3BDCC12013D5: removed


Oct 27 00:23:17 nge postfix/smtps/smtpd[3393]: 04DAF120115B:
client=pentiv.net.a
Oct 27 00:23:24 nge postfix/cleanup[3428]: 04DAF120115B:
message-id=<009b01d46d7
Oct 27 00:25:21 nge postfix/qmgr[14998]: 04DAF120115B: from=<Rainer@Domain1
Oct 27 00:25:21 nge postfix/encrypted/smtp[3491]: 04DAF120115B: to=<Rcpt1@bt
Oct 27 00:25:24 nge postfix/encrypted/smtp[3493]: 04DAF120115B:
to=<undisclosed@
Oct 27 00:25:24 nge postfix/encrypted/smtp[3485]: 04DAF120115B: to=<Rcpt7
Oct 27 00:25:27 nge postfix/encrypted/smtp[3579]: 04DAF120115B: to=<Rcpt4
Oct 27 00:25:27 nge postfix/encrypted/smtp[3492]: 04DAF120115B: to=<Rcpt8
Oct 27 00:25:27 nge postfix/encrypted/smtp[3492]: 04DAF120115B: to=<Rcpt9
Oct 27 00:25:27 nge postfix/encrypted/smtp[3492]: 04DAF120115B: to=<Rcpt10
Oct 27 00:25:28 nge postfix/encrypted/smtp[3533]: 04DAF120115B: to=<Rcpt3
Oct 27 00:25:29 nge postfix/encrypted/smtp[3488]: 04DAF120115B: to=<Rcpt2
Oct 27 00:25:29 nge postfix/encrypted/smtp[3486]: 04DAF120115B: to=<Rcpt5
Oct 27 00:25:29 nge postfix/encrypted/smtp[3486]: 04DAF120115B: to=<Rcpt6
Oct 27 00:25:29 nge postfix/encrypted/smtp[3496]: 04DAF120115B: to=<Rcpt11>,
Oct 27 00:25:30 nge postfix/encrypted/smtp[3581]: 04DAF120115B: to=<Rcpt12
Oct 27 00:25:32 nge postfix/encrypted/smtp[3494]: 04DAF120115B: to=<Rcpt15
Oct 27 00:25:43 nge postfix/encrypted/smtp[3580]: 04DAF120115B: to=<Rcpt14
Oct 27 00:25:51 nge postfix/encrypted/smtp[3487]: 04DAF120115B: to=<Rcpt13
Oct 27 00:25:51 nge postfix/bounce[3450]: 04DAF120115B: sender
non-delivery noti
Oct 27 00:25:51 nge postfix/bounce[3447]: 04DAF120115B: sender delay
notificatio
Oct 27 00:26:01 nge postfix/postsuper[3598]: 04DAF120115B: removed



Oct 27 00:25:28 nge postfix/smtps/smtpd[3543]: 22BEC12017AD:
client=pentiv.net.a
Oct 27 00:25:33 nge postfix/cleanup[3385]: 22BEC12017AD:
message-id=<00b401d46d7
Oct 27 00:27:28 nge postfix/qmgr[14998]: 22BEC12017AD: from=<Rainer@Domain1
Oct 27 00:27:29 nge postfix/encrypted/smtp[3487]: 22BEC12017AD: to=<Rcpt1@bt
Oct 27 00:27:32 nge postfix/encrypted/smtp[4064]: 22BEC12017AD:
to=<undisclosed@
Oct 27 00:27:32 nge postfix/encrypted/smtp[4058]: 22BEC12017AD: to=<Rcpt7
Oct 27 00:27:32 nge postfix/encrypted/smtp[4063]: 22BEC12017AD: to=<Rcpt5
Oct 27 00:27:32 nge postfix/encrypted/smtp[4063]: 22BEC12017AD: to=<Rcpt6
Oct 27 00:27:34 nge postfix/encrypted/smtp[4060]: 22BEC12017AD: to=<Rcpt3
Oct 27 00:27:36 nge postfix/encrypted/smtp[4057]: 22BEC12017AD: to=<Rcpt8
Oct 27 00:27:36 nge postfix/encrypted/smtp[4057]: 22BEC12017AD: to=<Rcpt9
Oct 27 00:27:36 nge postfix/encrypted/smtp[4057]: 22BEC12017AD: to=<Rcpt10
Oct 27 00:27:37 nge postfix/encrypted/smtp[4065]: 22BEC12017AD: to=<Rcpt4
Oct 27 00:27:37 nge postfix/encrypted/smtp[4056]: 22BEC12017AD: to=<Rcpt2
Oct 27 00:27:39 nge postfix/encrypted/smtp[4067]: 22BEC12017AD: to=<Rcpt12
Oct 27 00:27:40 nge postfix/encrypted/smtp[4062]: 22BEC12017AD: to=<Rcpt11>,
Oct 27 00:27:45 nge postfix/encrypted/smtp[4066]: 22BEC12017AD: to=<Rcpt14
Oct 27 00:27:53 nge postfix/encrypted/smtp[4059]: 22BEC12017AD: to=<Rcpt15
Oct 27 00:27:57 nge postfix/encrypted/smtp[4061]: 22BEC12017AD: to=<Rcpt13
Oct 27 00:27:57 nge postfix/bounce[4069]: 22BEC12017AD: sender
non-delivery noti
Oct 27 00:27:57 nge postfix/bounce[3447]: 22BEC12017AD: sender delay
notificatio
Oct 27 00:28:01 nge postfix/postsuper[4091]: 22BEC12017AD: removed



Am 01.11.18 um 15:36 schrieb Ralf Hildebrandt:

> * Peter Buettner <[hidden email]>:
>
>>> Vorsicht: Lange Cc: Listen könnten abmahnbar sein:
>>> https://www.e-recht24.de/news/datenschutz/7652-cc-an-alle-e-mails-datenschutzbehoerde-verhaengt-bussgeld-wegen-offenem-e-mail-verteiler.html
>
>> Das umgeht der Endanwender mit "To: [hidden email]"
>
> Dann hat er aber keine CC: Liste, sondern eine Bcc: Liste.
>
>>>> Alle 2 Minuten werden die CC's erneut mit der Mail beglückt. Nach dem
>>>> Abbruch einer solchen Spamtirade zeigte pflogsum, daß an die CC's 36
>>>> mal zugestellt wurde.
>>>
>>> Also an alle Empfänger? Alle zwei Minuten ist ja auch etwas seltsam,
>>> Postfix läßt ja bei Fehlern immer mehr Zeit zwischen zwei Versuchen.
>>> Vielleicht ruft Outlook alle 2 Minuten Mail ab und führt Regeln aus?
>>
>> 2 Minuten durchscnittlich. Unterschiedlich zwischen 1-3 minuten
>
> Man müsste bei den Mails genau die Header ansehen (insbes. Message-id
> und QueueID) und so feststellen, welches System diese Mails verdoppelt.
>
> Möglichkeiten:
>
> * Outlook schickt immer wieder - dann sollte man immer neue QueueIDs
>   sehen und eigentlich auch message-ids
>
> * ein Zwischensystem sendet die Mails immer wieder (z.B. weil dort ein
>   Virenscanner mit der Mail nicht klar kommt) - dann sollte in den
>   Header die die VORGELAGERTEN Systeme angelegt haben keine Änderung zu
>   sehn sein. Die anderen Header würden dann variieren.
>
Reply | Threaded
Open this post in threaded view
|

Re: [ext] Re: Spam über CC-Listen

Ralf Hildebrandt
* Peter Buettner <[hidden email]>:

> wie versprochen, die Auswertung des Logfiles. Von den 36 Einlieferungen
> nur die esten sechs.
>
> Weil der Server von Rcpt1 keine Transportverschlüsselung unterstützt,
> bekommt der Endanwender, ich habe ihn mal Rainer genannt, noch eine
> Benachrichtigung, daß an Rcpt1 nicht verschlüsselt geliefert werden kann
> und die Mail vom Server gelöscht wurde.
>
> Die Zeitstempel sind sehr merkwürdig. Es wird schon die nächste Mail
> eingeliefert, bevor qmgr angefangen hat zu arbeiten. Evt. habe ich auch
> etwas von der zeitlichen Abfolge der Verarbeitung falsch verstanden.
>
> Ich glaube nicht, daß Outlook von sich aus den Absender und die CC-Liste
> ändert. Der Endanwender hat Postfächer für zwei Domains.
>
> Peter Büttner
> AlsterCom e.K.
>
>
> Oct 27 00:17:32 nge postfix/smtps/smtpd[3393]: F38FC1201131: client=pentiv.net.a
> Oct 27 00:17:39 nge postfix/cleanup[3385]: F38FC1201131: message-id=<007c01d46d7
> Oct 27 00:19:36 nge postfix/qmgr[14998]: F38FC1201131: from=<Rainer@Domain1

Hier ist fertig eingeliefert; nun wird per SMTP zugestellt:

> Oct 27 00:19:36 nge postfix/encrypted/smtp[3434]: F38FC1201131: to=<Rcpt1@bt
> Oct 27 00:19:36 nge postfix/encrypted/smtp[3435]: F38FC1201131: host eu-smtp-inb
> Oct 27 00:19:37 nge postfix/encrypted/smtp[3435]: F38FC1201131: to=<Rcpt2
> Oct 27 00:19:38 nge postfix/encrypted/smtp[3443]: F38FC1201131: to=<undisclosed@
> Oct 27 00:19:39 nge postfix/encrypted/smtp[3439]: F38FC1201131: to=<Rcpt3
> Oct 27 00:19:40 nge postfix/encrypted/smtp[3444]: F38FC1201131: to=<Rcpt4
> Oct 27 00:19:41 nge postfix/encrypted/smtp[3442]: F38FC1201131: to=<Rcpt5
> Oct 27 00:19:41 nge postfix/encrypted/smtp[3442]: F38FC1201131: to=<Rcpt6
> Oct 27 00:19:41 nge postfix/encrypted/smtp[3437]: F38FC1201131: to=<Rcpt7
> Oct 27 00:19:43 nge postfix/encrypted/smtp[3436]: F38FC1201131: to=<Rcpt8
> Oct 27 00:19:43 nge postfix/encrypted/smtp[3436]: F38FC1201131: to=<Rcpt9
> Oct 27 00:19:43 nge postfix/encrypted/smtp[3436]: F38FC1201131: to=<Rcpt10
> Oct 27 00:19:44 nge postfix/encrypted/smtp[3441]: F38FC1201131: to=<Rcpt11>,
> Oct 27 00:19:45 nge postfix/encrypted/smtp[3446]: F38FC1201131: to=<Rcpt12
> Oct 27 00:19:46 nge postfix/encrypted/smtp[3440]: F38FC1201131: to=<Rcpt13
> Oct 27 00:19:54 nge postfix/encrypted/smtp[3445]: F38FC1201131: to=<Rcpt14
> Oct 27 00:20:06 nge postfix/encrypted/smtp[3438]: F38FC1201131: to=<Rcpt15
> Oct 27 00:20:06 nge postfix/bounce[3450]: F38FC1201131: sender non-delivery noti
> Oct 27 00:20:07 nge postfix/bounce[3447]: F38FC1201131: sender delay notificatio
Eine Minute Pause?
> Oct 27 00:21:01 nge postfix/postsuper[3476]: F38FC1201131: removed

Fertig.  Eine nicht zugestellt.

Das ist eine neue Mail (neue QueueID, neu Message-id):

> Oct 27 00:19:23 nge postfix/smtps/smtpd[3420]: CF8A412013D5: client=pentiv.net.a
> Oct 27 00:19:31 nge postfix/cleanup[3428]: CF8A412013D5: message-id=<008f01d46d7
> Oct 27 00:21:34 nge postfix/qmgr[14998]: CF8A412013D5: from=<Rainer@Domain1

Ich bin fasziniert davon, daß da zwei Minuten zwischen smptd
bzw. cleanup und dann dem qmgr liegen. Was passiert denn da?

> Oct 27 00:21:34 nge postfix/encrypted/smtp[3438]: CF8A412013D5: to=<Rcpt1@bt
> Oct 27 00:21:36 nge postfix/encrypted/smtp[3493]: CF8A412013D5: to=<undisclosed@
> Oct 27 00:21:37 nge postfix/encrypted/smtp[3492]: CF8A412013D5: to=<Rcpt5
> Oct 27 00:21:37 nge postfix/encrypted/smtp[3492]: CF8A412013D5: to=<Rcpt6
> Oct 27 00:21:39 nge postfix/encrypted/smtp[3487]: CF8A412013D5: to=<Rcpt7
> Oct 27 00:21:40 nge postfix/encrypted/smtp[3489]: CF8A412013D5: to=<Rcpt3
> Oct 27 00:21:41 nge postfix/encrypted/smtp[3486]: CF8A412013D5: to=<Rcpt8
> Oct 27 00:21:41 nge postfix/encrypted/smtp[3486]: CF8A412013D5: to=<Rcpt9
> Oct 27 00:21:41 nge postfix/encrypted/smtp[3486]: CF8A412013D5: to=<Rcpt10
> Oct 27 00:21:41 nge postfix/encrypted/smtp[3494]: CF8A412013D5: to=<Rcpt4
> Oct 27 00:21:42 nge postfix/encrypted/smtp[3491]: CF8A412013D5: to=<Rcpt11>,
> Oct 27 00:21:44 nge postfix/encrypted/smtp[3496]: CF8A412013D5: to=<Rcpt12
> Oct 27 00:21:51 nge postfix/encrypted/smtp[3485]: CF8A412013D5: to=<Rcpt2
> Oct 27 00:21:57 nge postfix/encrypted/smtp[3495]: CF8A412013D5: to=<Rcpt14
> Oct 27 00:22:00 nge postfix/encrypted/smtp[3488]: CF8A412013D5: to=<Rcpt15
> Oct 27 00:22:05 nge postfix/encrypted/smtp[3490]: CF8A412013D5: to=<Rcpt13
> Oct 27 00:22:05 nge postfix/bounce[3450]: CF8A412013D5: sender non-delivery noti
> Oct 27 00:22:05 nge postfix/bounce[3447]: CF8A412013D5: sender delay notificatio
1 Minute pause?
> Oct 27 00:23:01 nge postfix/postsuper[3526]: CF8A412013D5: removed

Ich finde auch die Zustellung recht langsam. Für 15 Mails 30 Sekunden?
process limit vielleicht auf 2?

> Oct 27 00:21:12 nge postfix/smtps/smtpd[3393]: 56C6A1201131: client=pentiv.net.a
> Oct 27 00:21:19 nge postfix/cleanup[3385]: 56C6A1201131: message-id=<009501d46d7
> Oct 27 00:23:14 nge postfix/qmgr[14998]: 56C6A1201131: from=<Rainer@Domain1
> Oct 27 00:23:14 nge postfix/encrypted/smtp[3493]: 56C6A1201131: to=<Rcpt1@bt
> Oct 27 00:23:17 nge postfix/encrypted/smtp[3488]: 56C6A1201131: to=<undisclosed@
> Oct 27 00:23:17 nge postfix/encrypted/smtp[3495]: 56C6A1201131: to=<Rcpt4
> Oct 27 00:23:20 nge postfix/encrypted/smtp[3494]: 56C6A1201131: to=<Rcpt5
> Oct 27 00:23:20 nge postfix/encrypted/smtp[3494]: 56C6A1201131: to=<Rcpt6
> Oct 27 00:23:20 nge postfix/encrypted/smtp[3489]: 56C6A1201131: to=<Rcpt3
> Oct 27 00:23:21 nge postfix/encrypted/smtp[3496]: 56C6A1201131: to=<Rcpt7
> Oct 27 00:23:23 nge postfix/encrypted/smtp[3486]: 56C6A1201131: to=<Rcpt11>,
> Oct 27 00:23:23 nge postfix/encrypted/smtp[3487]: 56C6A1201131: to=<Rcpt8
> Oct 27 00:23:23 nge postfix/encrypted/smtp[3487]: 56C6A1201131: to=<Rcpt9
> Oct 27 00:23:23 nge postfix/encrypted/smtp[3487]: 56C6A1201131: to=<Rcpt10
> Oct 27 00:23:24 nge postfix/encrypted/smtp[3492]: 56C6A1201131: to=<Rcpt2
> Oct 27 00:23:25 nge postfix/encrypted/smtp[3533]: 56C6A1201131: to=<Rcpt12
> Oct 27 00:23:26 nge postfix/encrypted/smtp[3490]: 56C6A1201131: to=<Rcpt15
> Oct 27 00:23:41 nge postfix/encrypted/smtp[3485]: 56C6A1201131: to=<Rcpt14
> Oct 27 00:23:44 nge postfix/encrypted/smtp[3491]: 56C6A1201131: to=<Rcpt13
> Oct 27 00:23:44 nge postfix/bounce[3450]: 56C6A1201131: sender non-delivery noti
> Oct 27 00:23:44 nge postfix/bounce[3447]: 56C6A1201131: sender delay notificatio
1:20 Pause
> Oct 27 00:25:01 nge postfix/postsuper[3571]: 56C6A1201131: removed

Das sind fast vier Minute für 15 Empfänger, ok. Vielleicht sind die
Mails groß und die Leitung dünn.

Für mich sieht das so aus als würde Outlook mehrfach die Mail
schicken. Immer neue Verbindungen, neue Message-Ids und QueueIds.

qmgr läuft durch, also kein postfix reload

--
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  [hidden email] | https://www.charite.de
           
Reply | Threaded
Open this post in threaded view
|

AW: [ext] Re: Spam über CC-Listen

Uwe Drießen
Im Auftrag von Ralf Hildebrandt
>
> Das sind fast vier Minute für 15 Empfänger, ok. Vielleicht sind die
> Mails groß und die Leitung dünn.

Das wäre sehr interessant zu wissen ob da Outlook evtl. in ein Timeout rennt weil die Mails zu groß, der Rechner zu langsam, die Leitung zu dünn

>
> Für mich sieht das so aus als würde Outlook mehrfach die Mail
> schicken. Immer neue Verbindungen, neue Message-Ids und QueueIds.
>

Das kommt das vor das Mails von Outlook mehrfach rausgeschickt werden.
Die bleiben im Postausgang hängen (muss von Hand gelöscht, neu erstellt und dann nochmal gesendet werden)
Oder die darauffolgende Mail irgendwie korrupt und da die in einer session gesendet werden die nachfolgende nicht als gesendet markiert  wird die davor ebenfalls immer wieder gesendet
Es guggt ja keiner in den Postausgang rein :-)
Da passiert erst dann wenn ein Empfänger anruft und fragt warum er die Mail denn schon 15 mal bekommen hat und danke sagt es reicht :-)  

Welche Outlookversion ist denn im Einsatz ?
Oder PST defekt / über 4GB groß/altes Outlook < 2010 ?  


Mit freundlichen Grüßen

Uwe Drießen
--
Software & Computer

Netzwerke, Server.
Wir vernetzen Sie und Ihre Rechner !

Uwe Drießen
Lembergstraße 33
67824 Feilbingert

Tel.: 06708660045


Reply | Threaded
Open this post in threaded view
|

Re: [ext] Re: Spam über CC-Listen

Peter Buettner


Am 02.11.18 um 10:53 schrieb Uwe Drießen:
> Im Auftrag von Ralf Hildebrandt
>>
>> Das sind fast vier Minute für 15 Empfänger, ok. Vielleicht sind die
>> Mails groß und die Leitung dünn.
>
Ein CC hat mit einer Art Greylistng verzögert. Die Auswertung ist nach
queue-ID zusammengefasst. Dazwischen waren natürlich noch andere
Aktivitäten.
> Das wäre sehr interessant zu wissen ob da Outlook evtl. in ein Timeout rennt weil die Mails zu groß, der Rechner zu langsam, die Leitung zu dünn
>anhänge zwi
Die Mails in dieser CC-Liste haben Anhänge zwischen 7 und 30 MB. Der
Rechner ist brandneu. Bis Kapstadt wird bitweise getrommelt, dann geht
es links um den Kontinent herum bis nach London. Von da nach Frankfurt
ins Decix. Unterwegs versucht jeder Bananenstaat nsa-mässig zu mauscheln.

>>
>> Für mich sieht das so aus als würde Outlook mehrfach die Mail
>> schicken. Immer neue Verbindungen, neue Message-Ids und QueueIds.
>>
>
> Das kommt das vor das Mails von Outlook mehrfach rausgeschickt werden.
> Die bleiben im Postausgang hängen (muss von Hand gelöscht, neu erstellt und dann nochmal gesendet werden)
> Oder die darauffolgende Mail irgendwie korrupt und da die in einer session gesendet werden die nachfolgende nicht als gesendet markiert  wird die davor ebenfalls immer wieder gesendet
> Es guggt ja keiner in den Postausgang rein :-)
> Da passiert erst dann wenn ein Empfänger anruft und fragt warum er die Mail denn schon 15 mal bekommen hat und danke sagt es reicht :-)  
>
Genauso ist es passiert. Es waren einmal 36, am nächsten Tag 39. Da ich
 Outlook nicht kenne, kann ich den Endanwender schlecht dabei
unterstützen, Outlook zu managen.
> Welche Outlookversion ist denn im Einsatz ?
> Oder PST defekt / über 4GB groß/altes Outlook < 2010 ?  
>
Outlook aus Office 2010, weil Outlook aus Office 365 nicht mit
bitdefender zusammen arbeiten mag.

>
> Mit freundlichen Grüßen
>
> Uwe Drießen
> --
> Software & Computer
>
> Netzwerke, Server.
> Wir vernetzen Sie und Ihre Rechner !
>
> Uwe Drießen
> Lembergstraße 33
> 67824 Feilbingert
>
> Tel.: 06708660045
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ext] Re: Spam über CC-Listen

Peter Buettner
In reply to this post by Ralf Hildebrandt


Am 02.11.18 um 10:05 schrieb Ralf Hildebrandt:

> * Peter Buettner <[hidden email]>:
>> wie versprochen, die Auswertung des Logfiles. Von den 36 Einlieferungen
>> nur die esten sechs.
>>
>> Weil der Server von Rcpt1 keine Transportverschlüsselung unterstützt,
>> bekommt der Endanwender, ich habe ihn mal Rainer genannt, noch eine
>> Benachrichtigung, daß an Rcpt1 nicht verschlüsselt geliefert werden kann
>> und die Mail vom Server gelöscht wurde.
>>
>> Die Zeitstempel sind sehr merkwürdig. Es wird schon die nächste Mail
>> eingeliefert, bevor qmgr angefangen hat zu arbeiten. Evt. habe ich auch
>> etwas von der zeitlichen Abfolge der Verarbeitung falsch verstanden.
>>
>> Ich glaube nicht, daß Outlook von sich aus den Absender und die CC-Liste
>> ändert. Der Endanwender hat Postfächer für zwei Domains.
>>
>> Peter Büttner
>> AlsterCom e.K.
>>
>>
>> Oct 27 00:17:32 nge postfix/smtps/smtpd[3393]: F38FC1201131: client=pentiv.net.a
>> Oct 27 00:17:39 nge postfix/cleanup[3385]: F38FC1201131: message-id=<007c01d46d7
>> Oct 27 00:19:36 nge postfix/qmgr[14998]: F38FC1201131: from=<Rainer@Domain1
>
> Hier ist fertig eingeliefert; nun wird per SMTP zugestellt:
>
>> Oct 27 00:19:36 nge postfix/encrypted/smtp[3434]: F38FC1201131: to=<Rcpt1@bt
>> Oct 27 00:19:36 nge postfix/encrypted/smtp[3435]: F38FC1201131: host eu-smtp-inb
>> Oct 27 00:19:37 nge postfix/encrypted/smtp[3435]: F38FC1201131: to=<Rcpt2
>> Oct 27 00:19:38 nge postfix/encrypted/smtp[3443]: F38FC1201131: to=<undisclosed@
>> Oct 27 00:19:39 nge postfix/encrypted/smtp[3439]: F38FC1201131: to=<Rcpt3
>> Oct 27 00:19:40 nge postfix/encrypted/smtp[3444]: F38FC1201131: to=<Rcpt4
>> Oct 27 00:19:41 nge postfix/encrypted/smtp[3442]: F38FC1201131: to=<Rcpt5
>> Oct 27 00:19:41 nge postfix/encrypted/smtp[3442]: F38FC1201131: to=<Rcpt6
>> Oct 27 00:19:41 nge postfix/encrypted/smtp[3437]: F38FC1201131: to=<Rcpt7
>> Oct 27 00:19:43 nge postfix/encrypted/smtp[3436]: F38FC1201131: to=<Rcpt8
>> Oct 27 00:19:43 nge postfix/encrypted/smtp[3436]: F38FC1201131: to=<Rcpt9
>> Oct 27 00:19:43 nge postfix/encrypted/smtp[3436]: F38FC1201131: to=<Rcpt10
>> Oct 27 00:19:44 nge postfix/encrypted/smtp[3441]: F38FC1201131: to=<Rcpt11>,
>> Oct 27 00:19:45 nge postfix/encrypted/smtp[3446]: F38FC1201131: to=<Rcpt12
>> Oct 27 00:19:46 nge postfix/encrypted/smtp[3440]: F38FC1201131: to=<Rcpt13
>> Oct 27 00:19:54 nge postfix/encrypted/smtp[3445]: F38FC1201131: to=<Rcpt14
>> Oct 27 00:20:06 nge postfix/encrypted/smtp[3438]: F38FC1201131: to=<Rcpt15
>> Oct 27 00:20:06 nge postfix/bounce[3450]: F38FC1201131: sender non-delivery noti
>> Oct 27 00:20:07 nge postfix/bounce[3447]: F38FC1201131: sender delay notificatio
> Eine Minute Pause?
>> Oct 27 00:21:01 nge postfix/postsuper[3476]: F38FC1201131: removed
>
> Fertig.  Eine nicht zugestellt.
>
> Das ist eine neue Mail (neue QueueID, neu Message-id):
>
>> Oct 27 00:19:23 nge postfix/smtps/smtpd[3420]: CF8A412013D5: client=pentiv.net.a
>> Oct 27 00:19:31 nge postfix/cleanup[3428]: CF8A412013D5: message-id=<008f01d46d7
>> Oct 27 00:21:34 nge postfix/qmgr[14998]: CF8A412013D5: from=<Rainer@Domain1
>
> Ich bin fasziniert davon, daß da zwei Minuten zwischen smptd
> bzw. cleanup und dann dem qmgr liegen. Was passiert denn da?
>
Das wüsste ich auch gerne. Evt. braucht es solange zum Hochladen.

>> Oct 27 00:21:34 nge postfix/encrypted/smtp[3438]: CF8A412013D5: to=<Rcpt1@bt
>> Oct 27 00:21:36 nge postfix/encrypted/smtp[3493]: CF8A412013D5: to=<undisclosed@
>> Oct 27 00:21:37 nge postfix/encrypted/smtp[3492]: CF8A412013D5: to=<Rcpt5
>> Oct 27 00:21:37 nge postfix/encrypted/smtp[3492]: CF8A412013D5: to=<Rcpt6
>> Oct 27 00:21:39 nge postfix/encrypted/smtp[3487]: CF8A412013D5: to=<Rcpt7
>> Oct 27 00:21:40 nge postfix/encrypted/smtp[3489]: CF8A412013D5: to=<Rcpt3
>> Oct 27 00:21:41 nge postfix/encrypted/smtp[3486]: CF8A412013D5: to=<Rcpt8
>> Oct 27 00:21:41 nge postfix/encrypted/smtp[3486]: CF8A412013D5: to=<Rcpt9
>> Oct 27 00:21:41 nge postfix/encrypted/smtp[3486]: CF8A412013D5: to=<Rcpt10
>> Oct 27 00:21:41 nge postfix/encrypted/smtp[3494]: CF8A412013D5: to=<Rcpt4
>> Oct 27 00:21:42 nge postfix/encrypted/smtp[3491]: CF8A412013D5: to=<Rcpt11>,
>> Oct 27 00:21:44 nge postfix/encrypted/smtp[3496]: CF8A412013D5: to=<Rcpt12
>> Oct 27 00:21:51 nge postfix/encrypted/smtp[3485]: CF8A412013D5: to=<Rcpt2
>> Oct 27 00:21:57 nge postfix/encrypted/smtp[3495]: CF8A412013D5: to=<Rcpt14
>> Oct 27 00:22:00 nge postfix/encrypted/smtp[3488]: CF8A412013D5: to=<Rcpt15
>> Oct 27 00:22:05 nge postfix/encrypted/smtp[3490]: CF8A412013D5: to=<Rcpt13
>> Oct 27 00:22:05 nge postfix/bounce[3450]: CF8A412013D5: sender non-delivery noti
>> Oct 27 00:22:05 nge postfix/bounce[3447]: CF8A412013D5: sender delay notificatio
> 1 Minute pause?
>> Oct 27 00:23:01 nge postfix/postsuper[3526]: CF8A412013D5: removed
>
> Ich finde auch die Zustellung recht langsam. Für 15 Mails 30 Sekunden?
> process limit vielleicht auf 2?
>
default_process_limit = 100
Alles läuft mit default Einstellungen.

>> Oct 27 00:21:12 nge postfix/smtps/smtpd[3393]: 56C6A1201131: client=pentiv.net.a
>> Oct 27 00:21:19 nge postfix/cleanup[3385]: 56C6A1201131: message-id=<009501d46d7
>> Oct 27 00:23:14 nge postfix/qmgr[14998]: 56C6A1201131: from=<Rainer@Domain1
>> Oct 27 00:23:14 nge postfix/encrypted/smtp[3493]: 56C6A1201131: to=<Rcpt1@bt
>> Oct 27 00:23:17 nge postfix/encrypted/smtp[3488]: 56C6A1201131: to=<undisclosed@
>> Oct 27 00:23:17 nge postfix/encrypted/smtp[3495]: 56C6A1201131: to=<Rcpt4
>> Oct 27 00:23:20 nge postfix/encrypted/smtp[3494]: 56C6A1201131: to=<Rcpt5
>> Oct 27 00:23:20 nge postfix/encrypted/smtp[3494]: 56C6A1201131: to=<Rcpt6
>> Oct 27 00:23:20 nge postfix/encrypted/smtp[3489]: 56C6A1201131: to=<Rcpt3
>> Oct 27 00:23:21 nge postfix/encrypted/smtp[3496]: 56C6A1201131: to=<Rcpt7
>> Oct 27 00:23:23 nge postfix/encrypted/smtp[3486]: 56C6A1201131: to=<Rcpt11>,
>> Oct 27 00:23:23 nge postfix/encrypted/smtp[3487]: 56C6A1201131: to=<Rcpt8
>> Oct 27 00:23:23 nge postfix/encrypted/smtp[3487]: 56C6A1201131: to=<Rcpt9
>> Oct 27 00:23:23 nge postfix/encrypted/smtp[3487]: 56C6A1201131: to=<Rcpt10
>> Oct 27 00:23:24 nge postfix/encrypted/smtp[3492]: 56C6A1201131: to=<Rcpt2
>> Oct 27 00:23:25 nge postfix/encrypted/smtp[3533]: 56C6A1201131: to=<Rcpt12
>> Oct 27 00:23:26 nge postfix/encrypted/smtp[3490]: 56C6A1201131: to=<Rcpt15
>> Oct 27 00:23:41 nge postfix/encrypted/smtp[3485]: 56C6A1201131: to=<Rcpt14
>> Oct 27 00:23:44 nge postfix/encrypted/smtp[3491]: 56C6A1201131: to=<Rcpt13
>> Oct 27 00:23:44 nge postfix/bounce[3450]: 56C6A1201131: sender non-delivery noti
>> Oct 27 00:23:44 nge postfix/bounce[3447]: 56C6A1201131: sender delay notificatio
> 1:20 Pause
>> Oct 27 00:25:01 nge postfix/postsuper[3571]: 56C6A1201131: removed
>
> Das sind fast vier Minute für 15 Empfänger, ok. Vielleicht sind die
> Mails groß und die Leitung dünn.
>
> Für mich sieht das so aus als würde Outlook mehrfach die Mail
> schicken. Immer neue Verbindungen, neue Message-Ids und QueueIds.
>
> qmgr läuft durch, also kein postfix reload
>
Reply | Threaded
Open this post in threaded view
|

AW: [ext] Re: Spam über CC-Listen

Uwe Drießen
In reply to this post by Peter Buettner
Von: Peter Buettner [mailto:[hidden email]]
> >
> > Das kommt das vor das Mails von Outlook mehrfach rausgeschickt werden.
> > Die bleiben im Postausgang hängen (muss von Hand gelöscht, neu erstellt
> und dann nochmal gesendet werden)

>>>>  muss von Hand gelöscht, neu erstellt und dann nochmal gesendet werden

Thats all, denn jets wida

> Genauso ist es passiert. Es waren einmal 36, am nächsten Tag 39. Da ich
>  Outlook nicht kenne, kann ich den Endanwender schlecht dabei
> unterstützen, Outlook zu managen.

Da muss nicht viel unterstützt werden, entweder es geht oder es geht nicht dann muss der Anwender den Postausgang kontrollieren.
Wenn er es selber nicht hinbekommt ich bin "käuflich" :-))

> > Welche Outlookversion ist denn im Einsatz ?
> > Oder PST defekt / über 4GB groß/altes Outlook < 2010 ?
> >
> Outlook aus Office 2010, weil Outlook aus Office 365 nicht mit
> bitdefender zusammen arbeiten mag.
> >

Und warum nicht ?
Weil ALLE Antivieren-Programme so Ihre Probs  mit SSL/TLS Verschlüsselung  haben :-)
Mir ist SSL/TLS aufgrund  der Datensicherheit wichtiger ist als Mails cleartext über den Äther zu senden nur damit ein Progrämmelchen die mail scannen kann.
Viren werden schon weit aus früher abgefangen und "the security is sitting between desk and chair" wenn da nix zwischen den Ohren ist dann hilft auch kein Antivirensystem.  

Stell mal die Verschlüsselung in der Verbindung in 2010 an dann hat Bitdefender auch seine Probs.
Office 365 ist außerdem zu teuer :-)

Mit freundlichen Grüßen

Uwe Drießen
--
Software & Computer

Netzwerke, Server.
Wir vernetzen Sie und Ihre Rechner !

Uwe Drießen
Lembergstraße 33
67824 Feilbingert

Tel.: 06708660045


Reply | Threaded
Open this post in threaded view
|

Re: [ext] Re: Spam über CC-Listen

Peter Buettner


Am 02.11.18 um 13:46 schrieb Uwe Drießen:

> Von: Peter Buettner [mailto:[hidden email]]
>>>
>>> Das kommt das vor das Mails von Outlook mehrfach rausgeschickt werden.
>>> Die bleiben im Postausgang hängen (muss von Hand gelöscht, neu erstellt
>> und dann nochmal gesendet werden)
>
>>>>>  muss von Hand gelöscht, neu erstellt und dann nochmal gesendet werden
>
> Thats all, denn jets wida
>
>> Genauso ist es passiert. Es waren einmal 36, am nächsten Tag 39. Da ich
>>  Outlook nicht kenne, kann ich den Endanwender schlecht dabei
>> unterstützen, Outlook zu managen.
>
> Da muss nicht viel unterstützt werden, entweder es geht oder es geht nicht dann muss der Anwender den Postausgang kontrollieren.
> Wenn er es selber nicht hinbekommt ich bin "käuflich" :-))
>
Das geb ich so weiter.

>>> Welche Outlookversion ist denn im Einsatz ?
>>> Oder PST defekt / über 4GB groß/altes Outlook < 2010 ?
>>>
>> Outlook aus Office 2010, weil Outlook aus Office 365 nicht mit
>> bitdefender zusammen arbeiten mag.
>>>
>
> Und warum nicht ?
> Weil ALLE Antivieren-Programme so Ihre Probs  mit SSL/TLS Verschlüsselung  haben :-)
> Mir ist SSL/TLS aufgrund  der Datensicherheit wichtiger ist als Mails cleartext über den Äther zu senden nur damit ein Progrämmelchen die mail scannen kann.
> Viren werden schon weit aus früher abgefangen und "the security is sitting between desk and chair" wenn da nix zwischen den Ohren ist dann hilft auch kein Antivirensystem.  
Dem kann ich nur zustimmen.
>
> Stell mal die Verschlüsselung in der Verbindung in 2010 an dann hat Bitdefender auch seine Probs.
> Office 365 ist außerdem zu teuer :-)
>
Die Verbindung ist verschlüsselt. Sonst könnte er den Server nicht
erreichen.


> Mit freundlichen Grüßen
>
> Uwe Drießen
> --
> Software & Computer
>
> Netzwerke, Server.
> Wir vernetzen Sie und Ihre Rechner !
>
> Uwe Drießen
> Lembergstraße 33
> 67824 Feilbingert
>
> Tel.: 06708660045
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ext] Re: Spam über CC-Listen

Peter Buettner
@Uwe Drießen
@Ralf Hildebrand

Ich bedanke mich für Eure Expertisen und Hilfestellungen. Weiter Tests
und die Lösungssuche haben etwas gedauert.

Das Outlookproblem und das Queueproblem lassen sich mit einer
Newslettersoftware lösen. Der Endanwender ist somit nicht auf Outlook
angewiesen und der Mailadministrator kann alles sauber nachvollziehen
und gezielt eingreifen, weil die Mails einzeln verschickt werden, und
eigene Message- und Queue-ID haben.
So lässt sich z.B. ein deferral wegen fehlender Transportverschlüsselung
aus der Queue löschen und extern behandeln, ohne die deferrals wegen
Verzögerung gleich mit wegzulöschen.

Wegen des Geschindigkeitproblems habe ich folgendes über eine Leitung
mit 10Mbit/s Upload getestet:

Mail mit 5,6MB Anhang:

x:10:46 connect
x:10:46 cleanup
x:10:53 qmgr
x:10:54 connect remote
x:10:55 removed

Eine Mail mit drei Rcpt's, 1'e DINA4 Seite Text, brauchte von connect
bis removed 2 Sekunden.
Über Mail Merge einzeln veschickt waren es 3 Sekunden.

Gibt es irgendwo Vergleichswerte?

Peter Büttner
AlsterCom e.K.



Am 02.11.18 um 16:04 schrieb Peter Buettner:

>
>
> Am 02.11.18 um 13:46 schrieb Uwe Drießen:
>> Von: Peter Buettner [mailto:[hidden email]]
>>>>
>>>> Das kommt das vor das Mails von Outlook mehrfach rausgeschickt werden.
>>>> Die bleiben im Postausgang hängen (muss von Hand gelöscht, neu erstellt
>>> und dann nochmal gesendet werden)
>>
>>>>>>  muss von Hand gelöscht, neu erstellt und dann nochmal gesendet werden
>>
>> Thats all, denn jets wida
>>
>>> Genauso ist es passiert. Es waren einmal 36, am nächsten Tag 39. Da ich
>>>  Outlook nicht kenne, kann ich den Endanwender schlecht dabei
>>> unterstützen, Outlook zu managen.
>>
>> Da muss nicht viel unterstützt werden, entweder es geht oder es geht nicht dann muss der Anwender den Postausgang kontrollieren.
>> Wenn er es selber nicht hinbekommt ich bin "käuflich" :-))
>>
> Das geb ich so weiter.
>
>>>> Welche Outlookversion ist denn im Einsatz ?
>>>> Oder PST defekt / über 4GB groß/altes Outlook < 2010 ?
>>>>
>>> Outlook aus Office 2010, weil Outlook aus Office 365 nicht mit
>>> bitdefender zusammen arbeiten mag.
>>>>
>>
>> Und warum nicht ?
>> Weil ALLE Antivieren-Programme so Ihre Probs  mit SSL/TLS Verschlüsselung  haben :-)
>> Mir ist SSL/TLS aufgrund  der Datensicherheit wichtiger ist als Mails cleartext über den Äther zu senden nur damit ein Progrämmelchen die mail scannen kann.
>> Viren werden schon weit aus früher abgefangen und "the security is sitting between desk and chair" wenn da nix zwischen den Ohren ist dann hilft auch kein Antivirensystem.  
> Dem kann ich nur zustimmen.
>>
>> Stell mal die Verschlüsselung in der Verbindung in 2010 an dann hat Bitdefender auch seine Probs.
>> Office 365 ist außerdem zu teuer :-)
>>
> Die Verbindung ist verschlüsselt. Sonst könnte er den Server nicht
> erreichen.
>
>
>> Mit freundlichen Grüßen
>>
>> Uwe Drießen
>> --
>> Software & Computer
>>
>> Netzwerke, Server.
>> Wir vernetzen Sie und Ihre Rechner !
>>
>> Uwe Drießen
>> Lembergstraße 33
>> 67824 Feilbingert
>>
>> Tel.: 06708660045
>>
>>