Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.os.unix.linux.misc > #124936 > unrolled thread
| Started by | Jan Novak <repcom@gmail.com> |
|---|---|
| First post | 2022-09-14 08:21 +0200 |
| Last post | 2022-09-15 09:08 +0000 |
| Articles | 20 on this page of 203 — 22 participants |
Back to article view | Back to de.comp.os.unix.linux.misc
Port Überprüfung von extern Jan Novak <repcom@gmail.com> - 2022-09-14 08:21 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 08:41 +0200
Re: Port Überprüfung von extern Jan Novak <repcom@gmail.com> - 2022-09-14 08:51 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 08:57 +0200
Re: Port Überprüfung von extern Jan Novak <repcom@gmail.com> - 2022-09-14 09:06 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 09:14 +0200
Re: Port Überprüfung von extern Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-14 07:40 +0000
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-14 14:32 +0200
Re: Port Überprüfung von extern Kay Martinen <usenet@martinen.de> - 2022-09-14 19:10 +0200
Re: Port Überprüfung von extern Laurenz Trossel <me@example.invalid> - 2022-09-15 09:08 +0000
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-15 11:49 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-16 00:32 +0200
Re: Port Überprüfung von extern Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2022-09-14 15:03 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-14 09:34 +0200
Re: Port Überprüfung von extern Jan Novak <repcom@gmail.com> - 2022-09-14 09:50 +0200
Re: Port Überprüfung von extern Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-14 09:30 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 09:44 +0200
Re: Port Überprüfung von extern Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-14 13:40 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 09:53 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 10:10 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 10:22 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 10:39 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 13:34 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 14:35 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 14:56 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 15:09 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 15:13 +0200
Re: Port Überprüfung von extern Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-14 20:11 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 20:43 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-15 11:51 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-15 18:28 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-15 19:37 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-15 19:52 +0200
Re: Port Überprüfung von extern Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-17 15:36 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-18 12:05 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-18 15:36 +0200
Re: Port Überprüfung von extern Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-18 21:58 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-18 22:23 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-19 08:11 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-19 09:47 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-19 09:55 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-19 14:23 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-19 16:10 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-19 16:47 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-19 16:58 +0200
Re: Port Überprüfung von extern Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-19 19:57 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-19 20:14 +0200
Re: Port Überprüfung von extern Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-19 20:39 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-19 20:47 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-19 14:22 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-19 16:13 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-19 16:50 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-19 17:01 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-20 12:42 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-20 13:52 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-15 11:51 +0200
Re: Port Überprüfung von extern Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-14 13:58 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 14:57 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 15:10 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 15:14 +0200
Re: Port Überprüfung von extern Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-14 20:12 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 20:43 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-15 05:19 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-15 05:27 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-16 00:35 +0200
Re: Port Überprüfung von extern Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-17 15:38 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-17 17:40 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-14 17:37 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 17:39 +0200
Re: Port Überprüfung von extern Rolf Buenning <r.buenning@gmx.de> - 2022-09-14 15:53 +0000
Re: Port Überprüfung von extern Wolfgang Kynast <wky@gmx.de> - 2022-09-14 18:44 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 19:06 +0200
Re: Port Überprüfung von extern Rolf Buenning <r.buenning@gmx.de> - 2022-09-15 06:17 +0000
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-15 08:20 +0200
Re: Port Überprüfung von extern Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-15 09:34 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-15 10:11 +0200
Re: Port Überprüfung von extern Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-15 10:31 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-17 17:56 +0200
Re: Port Überprüfung von extern Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-15 09:02 +0000
Re: Port Überprüfung von extern Joerg Lorenz <hugybear@gmx.ch> - 2022-09-15 18:08 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-16 00:36 +0200
Re: Port Überprüfung von extern Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-09-15 08:31 +0200
Re: Port Überprüfung von extern Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-15 09:35 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-17 17:57 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 20:44 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-15 08:21 +0200
Re: Port Überprüfung von extern Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-09-15 08:34 +0200
Re: Port Überprüfung von extern Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-15 09:28 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-15 11:53 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-16 00:42 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-17 17:42 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-18 10:38 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-18 15:35 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-18 17:06 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-19 14:23 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-14 14:39 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 14:58 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 15:11 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-14 15:16 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 16:28 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-14 17:42 +0200
Re: Port Überprüfung von extern Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-14 17:28 +0000
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 19:47 +0200
Re: Port Überprüfung von extern "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2022-09-15 00:27 +0200
Re: Port Überprüfung von extern Joerg Lorenz <hugybear@gmx.ch> - 2022-09-15 06:49 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-15 08:22 +0200
Re: Port Überprüfung von extern Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-15 08:47 +0000
Re: Port Überprüfung von extern Joerg Lorenz <hugybear@gmx.ch> - 2022-09-15 11:53 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-15 05:23 +0200
Re: Port Überprüfung von extern Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-15 09:42 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-15 11:02 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-16 00:45 +0200
Re: Port Überprüfung von extern Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-15 08:53 +0000
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-14 17:40 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-14 17:41 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 18:07 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-14 09:32 +0200
Re: Port Überprüfung von extern Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-14 07:37 +0000
Re: Port Überprüfung von extern Jan Novak <repcom@gmail.com> - 2022-09-14 15:13 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-14 16:30 +0200
Re: Port Überprüfung von extern Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-14 20:47 +0200
Re: Port Überprüfung von extern Kay Martinen <usenet@martinen.de> - 2022-09-14 21:42 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-15 08:15 +0200
Re: Port Überprüfung von extern Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-17 15:43 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-17 17:40 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-17 18:07 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-18 10:39 +0200
Re: Port Überprüfung von extern Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-18 22:00 +0200
Segment (was: Port Überprüfung von extern) Kay Martinen <usenet@martinen.de> - 2022-09-18 23:03 +0200
Re: Segment (was: Port Überprüfung von extern) Marco Moock <mo01@posteo.de> - 2022-09-19 08:09 +0200
Re: Segment (was: Port Überprüfung von extern) Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-19 14:14 +0200
Re: Segment (was: Port Überprüfung von extern) Kay Martinen <usenet@martinen.de> - 2022-09-19 19:19 +0200
Re: Segment (was: Port Überprüfung von extern) Marco Moock <mo01@posteo.de> - 2022-09-19 19:34 +0200
Re: Segment (was: Port Überprüfung von extern) Kay Martinen <usenet@martinen.de> - 2022-09-19 19:50 +0200
Re: Segment (was: Port Überprüfung von extern) Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-21 09:33 +0200
Re: Segment (was: Port Überprüfung von extern) Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-21 12:02 +0200
Re: Segment Arno Welzel <usenet@arnowelzel.de> - 2022-09-19 14:30 +0200
Re: Segment Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-19 16:30 +0200
Re: Segment Arno Welzel <usenet@arnowelzel.de> - 2022-09-19 16:51 +0200
Re: Segment Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-19 17:17 +0200
Re: Segment Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-21 09:35 +0200
Re: Segment Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 09:54 +0200
Re: Segment Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-21 12:08 +0200
Re: Segment Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 13:34 +0200
Re: Segment Joerg Lorenz <hugybear@gmx.ch> - 2022-09-21 10:32 +0200
Re: Segment Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-21 12:10 +0200
Re: Segment Joerg Lorenz <hugybear@gmx.ch> - 2022-09-21 14:28 +0200
Re: Segment Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-21 12:06 +0200
Re: Segment Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 13:35 +0200
Re: Segment Andreas Kohlbach <ank@spamfence.net> - 2022-09-21 08:02 -0400
Re: Segment Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-21 14:27 +0200
Re: Segment Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 15:11 +0200
Re: Segment Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-21 14:24 +0200
Re: Segment Joerg Lorenz <hugybear@gmx.ch> - 2022-09-21 14:31 +0200
Re: Segment Arno Welzel <usenet@arnowelzel.de> - 2022-09-21 17:52 +0200
OT: Aussprache (was Re: Segment) Michael Brand <brandm@gmx.net> - 2022-09-21 18:58 +0200
Re: OT: Aussprache (was Re: Segment) Joerg Lorenz <hugybear@gmx.ch> - 2022-09-21 19:06 +0200
Re: OT: Aussprache Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-21 21:44 +0000
Re: OT: Aussprache Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-22 05:54 +0000
Re: OT: Aussprache Joerg Lorenz <hugybear@gmx.ch> - 2022-09-22 08:56 +0200
Re: OT: Aussprache Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-22 09:54 +0200
Re: OT: Aussprache Joerg Lorenz <hugybear@gmx.ch> - 2022-09-22 08:56 +0200
Re: OT: Aussprache Arno Welzel <usenet@arnowelzel.de> - 2022-09-22 13:35 +0200
Re: OT: Aussprache Joerg Lorenz <hugybear@gmx.ch> - 2022-09-22 17:48 +0200
Re: OT: Aussprache Arno Welzel <usenet@arnowelzel.de> - 2022-09-26 13:40 +0200
Re: OT: Aussprache Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-26 14:07 +0200
Re: OT: Aussprache Joerg Lorenz <hugybear@gmx.ch> - 2022-09-26 16:54 +0200
Re: OT: Aussprache Patrick Rudin <taxi_bs@gmx.ch> - 2022-09-26 17:24 +0200
Re: OT: Aussprache Arno Welzel <usenet@arnowelzel.de> - 2022-10-09 20:59 +0200
Re: OT: Aussprache Joerg Lorenz <hugybear@gmx.ch> - 2022-10-09 23:21 +0200
Re: OT: Aussprache Arno Welzel <usenet@arnowelzel.de> - 2022-10-09 21:00 +0200
Re: OT: Aussprache (was Re: Segment) Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-22 12:06 +0200
Re: OT: Aussprache (was Re: Segment) Arno Welzel <usenet@arnowelzel.de> - 2022-09-22 13:33 +0200
Re: OT: Aussprache (was Re: Segment) Joerg Lorenz <hugybear@gmx.ch> - 2022-09-22 17:49 +0200
Re: OT: Aussprache (was Re: Segment) Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-23 10:40 +0000
Re: OT: Aussprache (was Re: Segment) Arno Welzel <usenet@arnowelzel.de> - 2022-09-26 13:42 +0200
Re: OT: Aussprache (was Re: Segment) Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-26 11:58 +0000
Re: OT: Aussprache (was Re: Segment) Joerg Lorenz <hugybear@gmx.ch> - 2022-09-26 16:56 +0200
Re: OT: Aussprache (was Re: Segment) Arno Welzel <usenet@arnowelzel.de> - 2022-10-09 21:02 +0200
Re: OT: Aussprache (was Re: Segment) Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-27 08:30 +0200
Re: OT: Aussprache (was Re: Segment) Joerg Lorenz <hugybear@gmx.ch> - 2022-09-22 09:00 +0200
Re: OT: Aussprache (was Re: Segment) Andreas Kohlbach <ank@spamfence.net> - 2022-09-22 09:26 -0400
Re: OT: Aussprache (was Re: Segment) Andreas Kohlbach <ank@spamfence.net> - 2022-09-22 12:22 -0400
Re: OT: Aussprache (was Re: Segment) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-09-22 17:56 +0000
Re: Segment Joerg Lorenz <hugybear@gmx.ch> - 2022-09-21 19:03 +0200
Re: Segment Arno Welzel <usenet@arnowelzel.de> - 2022-09-22 13:41 +0200
Re: Segment Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-09-21 20:08 +0200
Re: Segment Arno Welzel <usenet@arnowelzel.de> - 2022-09-22 13:42 +0200
Re: Segment Michael Brand <brandm@gmx.net> - 2022-09-22 15:55 +0200
Re: Segment Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2022-09-23 09:18 +0200
Re: Segment Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-22 09:50 +0200
Re: Segment Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-22 09:49 +0200
Re: Port Überprüfung von extern Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-09-18 23:40 +0200
Re: Port Überprüfung von extern Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-19 08:27 +0200
Re: Port Überprüfung von extern Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-19 14:13 +0200
Re: Port Überprüfung von extern Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-19 14:34 +0200
Re: Port Überprüfung von extern Paul Muster <exp-311222@news.muster.net> - 2022-09-19 19:52 +0200
Re: Port Überprüfung von extern Kay Martinen <usenet@martinen.de> - 2022-09-19 20:49 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-20 12:45 +0200
Re: Port Überprüfung von extern Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-19 05:32 +0200
Re: Port Überprüfung von extern Marco Moock <mo01@posteo.de> - 2022-09-19 08:08 +0200
Re: Port Überprüfung von extern Arno Welzel <usenet@arnowelzel.de> - 2022-09-19 14:28 +0200
Re: Port Überprüfung von extern Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-15 09:08 +0000
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-19 09:55 +0200 |
| Message-ID | <tg979n$11be2$1@dont-email.me> |
| In reply to | #125119 |
Am 19.09.2022 um 09:47 schrieb Bonita Montero: > So blöd wie Du denkst, dass ich es hier wäre hat nichtmal Marc > angenommen. > > Das Problem ist eigentlich, dass TCP nicht sowas wie ein NACK kennt mit > dem ein nicht offener Port meldet, dass "er" nicht erreichbar ist. Wäre > ne Idee, das nach-zu-spezifizieren. Das wäre ja völlig transparent für > Implementationen auf Client-Seite die das nicht können. > In dem Zusammenhang geht mir gerade durch den Kopf, dass man das Ganze > auch auf etablierter Technik ohne Erweiterungen des Paket-Formats aufb- > bauen könnte. Man müsste einfach nur einen ICMP-Meldung zurückwerfen die > sagt, dass das Paket Setver-seitig verworfen wurde. Der Stack auf dem > Client müsste sich dann das Paket genauer anschauen und sehen, dass > erstens diese ICMP-Meldung eben von dem Rechner kommt die er versucht > hat anzusprechchen und zweitens kriegt er ja sein eigenes Paket im > Content des ICMP-Paketes zurück und kann daran sehen auf welches SYN > das er verschickt hatte er reagieren muss bzw. welchen Verbindungs > -Versuch er damit abhaken soll. > Ach, ich seh gerade: dafür gibt es doch bereits eine ICMP-Meldung: Nachricht 3, Code 3: Ziel / Ziel-Port nicht erreichbar. Wird das verschickt, aber vom Client nicht ausgewertet oder wird das gar nicht verschickt ? Ich mein wenn das so ist, dass die Mail-Server die nicht erreichbar sind periodisch bis zu einem Limit regelmäßig gepollt werden, dann wird wohl eher letzteres der Fall sein.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2022-09-19 14:23 +0200 |
| Message-ID | <jor598Fn5uiU6@mid.individual.net> |
| In reply to | #125120 |
Bonita Montero, 2022-09-19 09:55: > Am 19.09.2022 um 09:47 schrieb Bonita Montero: > >> So blöd wie Du denkst, dass ich es hier wäre hat nichtmal Marc >> angenommen. >> >> Das Problem ist eigentlich, dass TCP nicht sowas wie ein NACK kennt mit >> dem ein nicht offener Port meldet, dass "er" nicht erreichbar ist. Wäre >> ne Idee, das nach-zu-spezifizieren. Das wäre ja völlig transparent für >> Implementationen auf Client-Seite die das nicht können. >> In dem Zusammenhang geht mir gerade durch den Kopf, dass man das Ganze >> auch auf etablierter Technik ohne Erweiterungen des Paket-Formats aufb- >> bauen könnte. Man müsste einfach nur einen ICMP-Meldung zurückwerfen die >> sagt, dass das Paket Setver-seitig verworfen wurde. Der Stack auf dem >> Client müsste sich dann das Paket genauer anschauen und sehen, dass >> erstens diese ICMP-Meldung eben von dem Rechner kommt die er versucht >> hat anzusprechchen und zweitens kriegt er ja sein eigenes Paket im >> Content des ICMP-Paketes zurück und kann daran sehen auf welches SYN >> das er verschickt hatte er reagieren muss bzw. welchen Verbindungs >> -Versuch er damit abhaken soll. >> > > Ach, ich seh gerade: dafür gibt es doch bereits eine ICMP-Meldung: > Nachricht 3, Code 3: Ziel / Ziel-Port nicht erreichbar. > Wird das verschickt, aber vom Client nicht ausgewertet oder wird das > gar nicht verschickt ? Ich mein wenn das so ist, dass die Mail-Server Weder noch. Ein Server, bei dem ein bestimmter Port nicht erreichbar ist, schickt diese Nachricht nicht. Das machen nur Gateways, die *andere* System erreichen sollen und das nicht können. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-19 16:10 +0200 |
| Message-ID | <tg9t8o$142om$3@dont-email.me> |
| In reply to | #125125 |
Am 19.09.2022 um 14:23 schrieb Arno Welzel: > Bonita Montero, 2022-09-19 09:55: > >> Am 19.09.2022 um 09:47 schrieb Bonita Montero: >> >>> So blöd wie Du denkst, dass ich es hier wäre hat nichtmal Marc >>> angenommen. >>> >>> Das Problem ist eigentlich, dass TCP nicht sowas wie ein NACK kennt mit >>> dem ein nicht offener Port meldet, dass "er" nicht erreichbar ist. Wäre >>> ne Idee, das nach-zu-spezifizieren. Das wäre ja völlig transparent für >>> Implementationen auf Client-Seite die das nicht können. >>> In dem Zusammenhang geht mir gerade durch den Kopf, dass man das Ganze >>> auch auf etablierter Technik ohne Erweiterungen des Paket-Formats aufb- >>> bauen könnte. Man müsste einfach nur einen ICMP-Meldung zurückwerfen die >>> sagt, dass das Paket Setver-seitig verworfen wurde. Der Stack auf dem >>> Client müsste sich dann das Paket genauer anschauen und sehen, dass >>> erstens diese ICMP-Meldung eben von dem Rechner kommt die er versucht >>> hat anzusprechchen und zweitens kriegt er ja sein eigenes Paket im >>> Content des ICMP-Paketes zurück und kann daran sehen auf welches SYN >>> das er verschickt hatte er reagieren muss bzw. welchen Verbindungs >>> -Versuch er damit abhaken soll. >>> >> >> Ach, ich seh gerade: dafür gibt es doch bereits eine ICMP-Meldung: >> Nachricht 3, Code 3: Ziel / Ziel-Port nicht erreichbar. >> Wird das verschickt, aber vom Client nicht ausgewertet oder wird das >> gar nicht verschickt ? Ich mein wenn das so ist, dass die Mail-Server > > Weder noch. Ein Server, bei dem ein bestimmter Port nicht erreichbar > ist, schickt diese Nachricht nicht. Das machen nur Gateways, die > *andere* System erreichen sollen und das nicht können. > > Äh, und wie weiß ein Gateway, dass ein Port auf einem Server nicht erreichbar ist ?
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2022-09-19 16:47 +0200 |
| Message-ID | <jordotFn5uiU16@mid.individual.net> |
| In reply to | #125130 |
Bonita Montero, 2022-09-19 16:10: > Am 19.09.2022 um 14:23 schrieb Arno Welzel: >> Bonita Montero, 2022-09-19 09:55: [...] >>> Ach, ich seh gerade: dafür gibt es doch bereits eine ICMP-Meldung: >>> Nachricht 3, Code 3: Ziel / Ziel-Port nicht erreichbar. >>> Wird das verschickt, aber vom Client nicht ausgewertet oder wird das >>> gar nicht verschickt ? Ich mein wenn das so ist, dass die Mail-Server >> >> Weder noch. Ein Server, bei dem ein bestimmter Port nicht erreichbar >> ist, schickt diese Nachricht nicht. Das machen nur Gateways, die >> *andere* System erreichen sollen und das nicht können. >> >> > > Äh, und wie weiß ein Gateway, dass ein Port auf einem Server nicht > erreichbar ist ? Indem es versucht, diesen Port zu erreichen. Dazu wurde es ja beauftragt. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-19 16:58 +0200 |
| Message-ID | <tga01v$14q8e$1@dont-email.me> |
| In reply to | #125133 |
Am 19.09.2022 um 16:47 schrieb Arno Welzel: > Bonita Montero, 2022-09-19 16:10: > >> Am 19.09.2022 um 14:23 schrieb Arno Welzel: >>> Bonita Montero, 2022-09-19 09:55: > [...] >>>> Ach, ich seh gerade: dafür gibt es doch bereits eine ICMP-Meldung: >>>> Nachricht 3, Code 3: Ziel / Ziel-Port nicht erreichbar. >>>> Wird das verschickt, aber vom Client nicht ausgewertet oder wird das >>>> gar nicht verschickt ? Ich mein wenn das so ist, dass die Mail-Server >>> >>> Weder noch. Ein Server, bei dem ein bestimmter Port nicht erreichbar >>> ist, schickt diese Nachricht nicht. Das machen nur Gateways, die >>> *andere* System erreichen sollen und das nicht können. >>> >>> >> >> Äh, und wie weiß ein Gateway, dass ein Port auf einem Server nicht >> erreichbar ist ? > > Indem es versucht, diesen Port zu erreichen. Dazu wurde es ja beauftragt. > Au weia. Das Gateway macht an der Stelle gar nix was den Verbindungs -State berifft. Es leitet nur das Paket weiter und kümmert sich sonst um nix was mit der Verbindung zu tun hat.
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz-usenet@rotfl.franken.de> |
|---|---|
| Date | 2022-09-19 19:57 +0200 |
| Message-ID | <20220919195718.48d37126.dietz-usenet@rotfl.franken.de> |
| In reply to | #125133 |
Arno Welzel <usenet@arnowelzel.de> wrote: > Bonita Montero, 2022-09-19 16:10: > > > Am 19.09.2022 um 14:23 schrieb Arno Welzel: > >> Bonita Montero, 2022-09-19 09:55: > [...] > >>> Ach, ich seh gerade: dafür gibt es doch bereits eine ICMP-Meldung: > >>> Nachricht 3, Code 3: Ziel / Ziel-Port nicht erreichbar. > >>> Wird das verschickt, aber vom Client nicht ausgewertet oder wird > >>> das gar nicht verschickt ? Ich mein wenn das so ist, dass die > >>> Mail-Server > >> > >> Weder noch. Ein Server, bei dem ein bestimmter Port nicht > >> erreichbar ist, schickt diese Nachricht nicht. Das machen nur > >> Gateways, die *andere* System erreichen sollen und das nicht > >> können. > > > > Äh, und wie weiß ein Gateway, dass ein Port auf einem Server nicht > > erreichbar ist ? > > Indem es versucht, diesen Port zu erreichen. Dazu wurde es ja > beauftragt. Soso. Das Gateway produziert in dem Fall ein ICMP 3.3. Du solltest dringend mit dem Autor von RFC 792 sprechen, Postel hat das '81 offenbar komplett falsch aufgeschrieben!!111 Und irgendwas war da auch mit UDP und TCP-Rst ... Kinder, Kinder. -- SIC SEMPER +--|=======> TYRANNIS
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-09-19 20:14 +0200 |
| Message-ID | <tgabio$16n2u$5@dont-email.me> |
| In reply to | #125144 |
Am Montag, 19. September 2022, um 19:57:18 Uhr schrieb Dietz Proepper: > Soso. Das Gateway produziert in dem Fall ein ICMP 3.3. Ein Router produziert immer dann ein ICMP-Paket, wenn er den Host nicht erreichen kann. Da gibt es 2 Fälle: keine Route, keine Antwort auf ARP/NDP. Dafür gibt es 2 separate ICMP-Nachrichten. Code/Type im passenden RFC nachlesen. > Du solltest dringend mit dem Autor von RFC 792 sprechen, Postel hat > das '81 offenbar komplett falsch aufgeschrieben!!111 > > Und irgendwas war da auch mit UDP und TCP-Rst ... Bei TCP kommt ein TCP mit gesetztem RST-Flag. Das sorgt dann für Meldungen wie "Connection refused". Bei UDP kommt gar nichts. Es wird aber ein ICMP-Paket "Port unreachable" generiert. All das ist der Normalzustand, in manchen Fällen werden Pakete durch Firewalls unterdrückt (wovon ich gerade bei ICMP dringend abrate).
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz-usenet@rotfl.franken.de> |
|---|---|
| Date | 2022-09-19 20:39 +0200 |
| Message-ID | <20220919203932.6f2d0ae4.dietz-usenet@rotfl.franken.de> |
| In reply to | #125149 |
Marco Moock <mo01@posteo.de> wrote: > Am Montag, 19. September 2022, um 19:57:18 Uhr schrieb Dietz Proepper: > > > Soso. Das Gateway produziert in dem Fall ein ICMP 3.3. > > Ein Router produziert immer dann ein ICMP-Paket, wenn er den Host > nicht erreichen kann. Da gibt es 2 Fälle: keine Route, keine Antwort > auf ARP/NDP. Dafür gibt es 2 separate ICMP-Nachrichten. Code/Type im > passenden RFC nachlesen. Ein Router wird nie ein 3.3 erzeugen. > > Du solltest dringend mit dem Autor von RFC 792 sprechen, Postel hat > > das '81 offenbar komplett falsch aufgeschrieben!!111 > > > > Und irgendwas war da auch mit UDP und TCP-Rst ... > > Bei TCP kommt ein TCP mit gesetztem RST-Flag. Das sorgt dann für > Meldungen wie "Connection refused". > > Bei UDP kommt gar nichts. Es wird aber ein ICMP-Paket "Port > unreachable" generiert. Exakt. > All das ist der Normalzustand, in manchen Fällen werden Pakete durch > Firewalls unterdrückt (wovon ich gerade bei ICMP dringend abrate). Sagen wir es so - man sollte wissen was man macht. -- SIC SEMPER +--|=======> TYRANNIS
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-09-19 20:47 +0200 |
| Message-ID | <tgadgl$16n2u$6@dont-email.me> |
| In reply to | #125150 |
Am Montag, 19. September 2022, um 20:39:32 Uhr schrieb Dietz Proepper: > Sagen wir es so - man sollte wissen was man macht. Es gibt ein ICMP-Paket, was man eingehend blockieren könnte, wäre der echo request. Wobei mir da eine Limitierung der Antworten lieber wäre, so wäre akzeptable Nutzung zum Test möglich. Alles andere von ICMP sollte man durchlassen, gerade packet too big, nur das wird an mancher Stelle ignoriert.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2022-09-19 14:22 +0200 |
| Message-ID | <jor57dFn5uiU5@mid.individual.net> |
| In reply to | #125119 |
Bonita Montero, 2022-09-19 09:47: [...] > Das Problem ist eigentlich, dass TCP nicht sowas wie ein NACK kennt mit > dem ein nicht offener Port meldet, dass "er" nicht erreichbar ist. Wäre Aber sicher gibt es das. Siehe <https://www.rfc-editor.org/rfc/rfc793> > In dem Zusammenhang geht mir gerade durch den Kopf, dass man das Ganze > auch auf etablierter Technik ohne Erweiterungen des Paket-Formats aufb- > bauen könnte. Man müsste einfach nur einen ICMP-Meldung zurückwerfen die > sagt, dass das Paket Setver-seitig verworfen wurde. Der Stack auf dem [...] Oder man könnte einfach TCP korrekt nutzen. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-19 16:13 +0200 |
| Message-ID | <tg9tcn$142om$4@dont-email.me> |
| In reply to | #125124 |
Am 19.09.2022 um 14:22 schrieb Arno Welzel: > Bonita Montero, 2022-09-19 09:47: > > [...] >> Das Problem ist eigentlich, dass TCP nicht sowas wie ein NACK kennt mit >> dem ein nicht offener Port meldet, dass "er" nicht erreichbar ist. Wäre > > Aber sicher gibt es das. > > Siehe <https://www.rfc-editor.org/rfc/rfc793> Ja, aber wenn das regelmäßig genutzt wäre, dann käme es nicht zu Timeouts - was die Regel ist. >> In dem Zusammenhang geht mir gerade durch den Kopf, dass man das Ganze >> auch auf etablierter Technik ohne Erweiterungen des Paket-Formats aufb- >> bauen könnte. Man müsste einfach nur einen ICMP-Meldung zurückwerfen die >> sagt, dass das Paket Setver-seitig verworfen wurde. Der Stack auf dem > [...] > > Oder man könnte einfach TCP korrekt nutzen. Echt, Du bist sowas von blöd.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2022-09-19 16:50 +0200 |
| Message-ID | <jordtgFn5uiU17@mid.individual.net> |
| In reply to | #125131 |
Bonita Montero, 2022-09-19 16:13: > Am 19.09.2022 um 14:22 schrieb Arno Welzel: >> Bonita Montero, 2022-09-19 09:47: >> >> [...] >>> Das Problem ist eigentlich, dass TCP nicht sowas wie ein NACK kennt mit >>> dem ein nicht offener Port meldet, dass "er" nicht erreichbar ist. Wäre >> >> Aber sicher gibt es das. >> >> Siehe <https://www.rfc-editor.org/rfc/rfc793> > > Ja, aber wenn das regelmäßig genutzt wäre, dann käme es nicht zu > Timeouts - was die Regel ist. Timeouts entstehen vor Allem durch Firewalls, die derlei unterbinden. Gerne werden auch diverse ICMP-Nachrichten von Firewalls unterdrückt, weil das angeblich "sicher" ist. >>> In dem Zusammenhang geht mir gerade durch den Kopf, dass man das Ganze >>> auch auf etablierter Technik ohne Erweiterungen des Paket-Formats aufb- >>> bauen könnte. Man müsste einfach nur einen ICMP-Meldung zurückwerfen die >>> sagt, dass das Paket Setver-seitig verworfen wurde. Der Stack auf dem >> [...] >> >> Oder man könnte einfach TCP korrekt nutzen. > > Echt, Du bist sowas von blöd. Wieso? TCP sieht alles, was Du willst, bereits vor. Es muss halt auch benutzt werden. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-19 17:01 +0200 |
| Message-ID | <tga088$14q8e$2@dont-email.me> |
| In reply to | #125134 |
Am 19.09.2022 um 16:50 schrieb Arno Welzel: > Bonita Montero, 2022-09-19 16:13: > >> Am 19.09.2022 um 14:22 schrieb Arno Welzel: >>> Bonita Montero, 2022-09-19 09:47: >>> >>> [...] >>>> Das Problem ist eigentlich, dass TCP nicht sowas wie ein NACK kennt mit >>>> dem ein nicht offener Port meldet, dass "er" nicht erreichbar ist. Wäre >>> >>> Aber sicher gibt es das. >>> >>> Siehe <https://www.rfc-editor.org/rfc/rfc793> >> >> Ja, aber wenn das regelmäßig genutzt wäre, dann käme es nicht zu >> Timeouts - was die Regel ist. > > Timeouts entstehen vor Allem durch Firewalls, die derlei unterbinden. Wieso sollte eine Firewall so eine sinnvolle Meldung unterdrücken. Das ergibt keinen Sinn. Und ich mein das mag im Einzelfall ab und zu sogar passieren, aber ich habe das mit mehreren Hosts im Netz ausprobiert und ich bekam immer ein Timeout, und die Admins sind sicher nicht so durchgängig blöd, dass die so eine sinnvolle Meldung zusätzlich unterdrücken. > Gerne werden auch diverse ICMP-Nachrichten von Firewalls unterdrückt, > weil das angeblich "sicher" ist. Du versuchst indirekt dein besseres Wissen von deiner These vorhin zu begründen indem Du hier etwas präsentierst was natürlich offensichtlich ist; dadurch wird das vorab Gesagte aber nicht richtiger. > >>>> In dem Zusammenhang geht mir gerade durch den Kopf, dass man das Ganze >>>> auch auf etablierter Technik ohne Erweiterungen des Paket-Formats aufb- >>>> bauen könnte. Man müsste einfach nur einen ICMP-Meldung zurückwerfen die >>>> sagt, dass das Paket Setver-seitig verworfen wurde. Der Stack auf dem >>> [...] >>> >>> Oder man könnte einfach TCP korrekt nutzen. >> >> Echt, Du bist sowas von blöd. > > Wieso? TCP sieht alles, was Du willst, bereits vor. Es muss halt auch > benutzt werden. > Du willst hier indirekt dein umfassendes Wissen um das Thema zum Ausdruck bringen; und das bei dem was Du da oben sagtest ...
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2022-09-20 12:42 +0200 |
| Message-ID | <jotjnrF4b17U2@mid.individual.net> |
| In reply to | #125137 |
Bonita Montero, 2022-09-19 17:01: > Am 19.09.2022 um 16:50 schrieb Arno Welzel: >> Bonita Montero, 2022-09-19 16:13: >> >>> Am 19.09.2022 um 14:22 schrieb Arno Welzel: >>>> Bonita Montero, 2022-09-19 09:47: >>>> >>>> [...] >>>>> Das Problem ist eigentlich, dass TCP nicht sowas wie ein NACK kennt mit >>>>> dem ein nicht offener Port meldet, dass "er" nicht erreichbar ist. Wäre >>>> >>>> Aber sicher gibt es das. >>>> >>>> Siehe <https://www.rfc-editor.org/rfc/rfc793> >>> >>> Ja, aber wenn das regelmäßig genutzt wäre, dann käme es nicht zu >>> Timeouts - was die Regel ist. >> >> Timeouts entstehen vor Allem durch Firewalls, die derlei unterbinden. > > Wieso sollte eine Firewall so eine sinnvolle Meldung unterdrücken. Weil sie so konfiguriert wurde. Ich hatte auch schon Firewalls, die die Verwendugn von Let's Encrypt verhindert haben, indem Sie den Zugriff auf acme-v02.api.letsencrypt.org mit der Begründung "ACME-Protkoll gesperrt" unterbunden haben. Die IP-Adresse war erreichbar, aber das, was dort hin gesendet wurde, mochte die Firewall nicht durchlassen. Im Umfeld von Firmen, die allerlei "Sicherheitsprodukte" einsetzen, ist alles möglich. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-20 13:52 +0200 |
| Message-ID | <tgc9gb$1g788$2@dont-email.me> |
| In reply to | #125158 |
Am 20.09.2022 um 12:42 schrieb Arno Welzel: > Bonita Montero, 2022-09-19 17:01: > >> Am 19.09.2022 um 16:50 schrieb Arno Welzel: >>> Bonita Montero, 2022-09-19 16:13: >>> >>>> Am 19.09.2022 um 14:22 schrieb Arno Welzel: >>>>> Bonita Montero, 2022-09-19 09:47: >>>>> >>>>> [...] >>>>>> Das Problem ist eigentlich, dass TCP nicht sowas wie ein NACK kennt mit >>>>>> dem ein nicht offener Port meldet, dass "er" nicht erreichbar ist. Wäre >>>>> >>>>> Aber sicher gibt es das. >>>>> >>>>> Siehe <https://www.rfc-editor.org/rfc/rfc793> >>>> >>>> Ja, aber wenn das regelmäßig genutzt wäre, dann käme es nicht zu >>>> Timeouts - was die Regel ist. >>> >>> Timeouts entstehen vor Allem durch Firewalls, die derlei unterbinden. >> >> Wieso sollte eine Firewall so eine sinnvolle Meldung unterdrücken. > > Weil sie so konfiguriert wurde. Das mag im Einzelfall so sein, aber so verpolt sind die Amins sicher nicht mehrheitlich. > Ich hatte auch schon Firewalls, die die Verwendugn von Let's Encrypt > verhindert haben, indem Sie den Zugriff auf acme-v02.api.letsencrypt.org > mit der Begründung "ACME-Protkoll gesperrt" unterbunden haben. Die > IP-Adresse war erreichbar, aber das, was dort hin gesendet wurde, mochte > die Firewall nicht durchlassen. Ja, damit muss ja jede blödsinnige Einstellung bei Admins _flächendeckend_ möglich sein, ne ? > > Im Umfeld von Firmen, die allerlei "Sicherheitsprodukte" einsetzen, ist > alles möglich. > >
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-09-15 11:51 +0200 |
| Message-ID | <tfusip$3901u$7@dont-email.me> |
| In reply to | #125018 |
Am Mittwoch, 14. September 2022, um 20:11:53 Uhr schrieb Marc Haber: > Bonita Montero <Bonita.Montero@gmail.com> wrote: > >Am 14.09.2022 um 14:35 schrieb Marco Moock: > > > >> Du hast es halt noch immer nicht verstanden. Ich werde dir da nicht > >> helfen, aber ich gehe darauf auch nicht mehr drauf ein, weil es > >> sinnlos ist. > > > >Wenn mein MTA einen MX ausmacht, dann ist gegenüber dem eine > >Authentisierung sinnlos. > > Was ist ein Smarthost? Spannende Frage, irgendwo habe ich mal gelesen, dass das ein Rechner sein soll, der gut angebunden ist. Kommt wohl noch aus UUCP-Zeiten. Bei sendmail bedeutet diese Variable, dass alle nicht-lokalen Mails an diesen Rechner geschickt werden. Das kann dann ein beliebiger Mailer sein, auch uucp sollte gehen. Mailertable hat aber Vorrang vor Smarthost.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-09-14 13:58 +0200 |
| Message-ID | <tfsfkf$37e5f$1@news1.tnib.de> |
| In reply to | #124960 |
Bonita Montero <Bonita.Montero@gmail.com> wrote: >Da das nicht der Regelfall ist kann man damit auch kein >Spam verhindern. Bitte lerne die Grundlagen von E-Mail. Es hilft unglaublich, wenn Residential Customers nicht mehr direkt auf Port 25 "fremder" Mailserver connecten dürfen, und zwar unabhängig davon, ob der Provider des Residential Customer oder der Mailserver selbst dies sicherstellt; beide Arten dieser Maßnahme kommen regelmäßig vor. -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-14 14:57 +0200 |
| Message-ID | <tfsj2i$2uvaj$2@dont-email.me> |
| In reply to | #124977 |
Am 14.09.2022 um 13:58 schrieb Marc Haber: > Bitte lerne die Grundlagen von E-Mail. Es hilft unglaublich, wenn > Residential Customers nicht mehr direkt auf Port 25 "fremder" > Mailserver connecten dürfen, und zwar unabhängig davon, ob der > Provider des Residential Customer oder der Mailserver selbst dies > sicherstellt; beide Arten dieser Maßnahme kommen regelmäßig vor. Wie soll das bitte gehen wenn ich einen MTA habe und der macht einen MX aus mit dem er nicht verwandt oder verschwägert ist und der soll sich gegenüber den authentisieren ?
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-09-14 15:10 +0200 |
| Message-ID | <tfsjrf$2ucbk$7@dont-email.me> |
| In reply to | #124985 |
Am Mittwoch, 14. September 2022, um 14:57:08 Uhr schrieb Bonita Montero: > Wie soll das bitte gehen wenn ich einen MTA habe und der macht > einen MX aus mit dem er nicht verwandt oder verschwägert ist > und der soll sich gegenüber den authentisieren ? Ein SMTP-Server kann gleichzeitig mehrere Rollen einnehmen, einfach mal die sendmail-Doku lesen, da ist das dokumentiert. Auch das Deutschbuch mit den Grammatik-Regeln lege ich dir nahe.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-14 15:14 +0200 |
| Message-ID | <tfsk33$2v79l$2@dont-email.me> |
| In reply to | #124988 |
Am 14.09.2022 um 15:10 schrieb Marco Moock: > Am Mittwoch, 14. September 2022, um 14:57:08 Uhr schrieb Bonita Montero: > >> Wie soll das bitte gehen wenn ich einen MTA habe und der macht >> einen MX aus mit dem er nicht verwandt oder verschwägert ist >> und der soll sich gegenüber den authentisieren ? > > Ein SMTP-Server kann gleichzeitig mehrere Rollen einnehmen, ... Danke, ohne dich hätt ich das nicht gewusst.
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | de.comp.os.unix.linux.misc
csiph-web