Hallo killerbees19 und tldev,
das mit dem Port 587 überleg ich mir - ja, ich weiß dass das mittlerweile Standard ist, aber ich bin immer sehr vorsichtig mit dem öffnen eines Ports nach drausen und dem erhöhen der Komplexität der Installation.
Ich wollte den Postfix so nahe wie möglich am Paketquellen Standard von Ubuntu 16.04 lassen, und da ist Port 587 noch nicht vorgesehen.
Eventuell mach ich das mal, vielen dank für den Tipp!
Thomas
Ich hab hier mal (mit Sysbench) den 'Root-Server M SSD v6' und den 'RS 2000 SSD G7' verglichen.
Ich fürchte es sieht so aus als wäre mit den neuen Servern alles besser 
Prozessor-Speed Root-Server M SSD v6:
sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 run
total time: 17.2203s
total number of events: 10000
total time taken by event execution: 68.8372
per-request statistics:
min: 3.08ms
avg: 6.88ms
max: 57.25ms
approx. 95 percentile: 11.91msProzessor-Speed RS 2000 SSD G7:
sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 run
total time: 13.3387s
total number of events: 10000
total time taken by event execution: 53.3168
per-request statistics:
min: 2.28ms
avg: 5.33ms
max: 23.31ms
approx. 95 percentile: 11.14msRAM Speed Root-Server M SSD v6:
sysbench --num-threads=4 --test=memory --memory-block-size=1M --memory-total-size=10G run
total time: 1.2534s
total number of events: 10240
total time taken by event execution: 4.9816
per-request statistics:
min: 0.16ms
avg: 0.49ms
max: 16.28ms
approx. 95 percentile: 0.41msRAM Speed RS 2000 SSD G7:
sysbench --num-threads=4 --test=memory --memory-block-size=1M --memory-total-size=10G run
total time: 0.7228s
total number of events: 10240
total time taken by event execution: 2.8693
per-request statistics:
min: 0.13ms
avg: 0.28ms
max: 16.26ms
approx. 95 percentile: 0.22msSSD Speed Root-Server M SSD v6:
sysbench --num-threads=4 --test=fileio --file-fsync-freq=1 --file-num=1 --file-total-size=16384 --file-test-mode=rndwr run
total time: 4.9604s
total number of events: 10012
total time taken by event execution: 1.2897
per-request statistics:
min: 0.00ms
avg: 0.13ms
max: 57.01ms
approx. 95 percentile: 0.33msSSD Speed RS 2000 SSD G7:
sysbench --num-threads=4 --test=fileio --file-fsync-freq=1 --file-num=1 --file-total-size=16384 --file-test-mode=rndwr run
total time: 2.8639s
total number of events: 10035
total time taken by event execution: 1.0012
per-request statistics:
min: 0.01ms
avg: 0.10ms
max: 4.15ms
approx. 95 percentile: 0.27msSSD Speed direct write Root-Server M SSD v6:
dd if=/dev/zero of=test.file bs=128M count=10 oflag=direct
10+0 records in
10+0 records out
1342177280 bytes (1.3 GB, 1.2 GiB) copied, 1.12019 s, 1.2 GB/sSSD Speed direct write Root-Server M SSD v6: RS 2000 SSD G7:
dd if=/dev/zero of=test.file bs=128M count=10 oflag=direct
10+0 records in
10+0 records out
1342177280 bytes (1.3 GB, 1.2 GiB) copied, 1.02251 s, 1.3 GB/sThomas
Ich denke ich habs.
Aus der Zeile:
smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10023Muss werden
smtpd_recipient_restrictions = permit_sasl_authenticated, check_policy_service inet:127.0.0.1:10023Korrekt?
Scheint nämlich das gewünschte Ergebnis zu bringen!
Thomas
@killerbees:
Hier die 'main.cf'.
Ist eigentlich ziemlich standard:
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = test.example.de
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, example.de, test.example.de, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
local_recipient_maps = hash:/etc/postfix/virtual
virtual_alias_maps = hash:/etc/postfix/virtual
home_mailbox = mails/
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
broken_sasl_auth_clients = yes
content_filter=smtp-amavis:[127.0.0.1]:10024
smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10023Natürlich, böser Fehler.
Senden tu ich über SMTP Port 25.
Aber das Greylisting bekomme ich auch wenn ich Postgrey manuell per Telnet anspreche.
Beispiel der Datei '/etc/postgrey/whitelist_clients':
hello@world.comBeispiel der Datei '/etc/postgrey/whitelist_recipients':
gibts@net.deAufruf Postgrey mit:
telnet 127.0.0.1 10023Versuch zum White-gelisteten Empfänger zu senden:
request=smtpd_access_policy
protocol_state=RCPT
protocol_name=ESMTP
client_address=127.0.0.1
client_name=dummy.de
helo_name=dummy.de
sender=me@dummy.de
recipient=gibts@net.de
queue_id=
instance=66cf.46d5964c.0
size=0
sasl_method=
sasl_username=
sasl_sender=
ccert_subject=
ccert_issuer=
ccert_fingerprint=
Geht:
action=DUNNOVersuch vom White-gelisteten Absender zu senden:
request=smtpd_access_policy
protocol_state=RCPT
protocol_name=ESMTP
client_address=127.0.0.1
client_name=dummy.de
helo_name=dummy.de
sender=hello@world.com
recipient=gibts2@net.de
queue_id=
instance=66cf.46d5964c.0
size=0
sasl_method=
sasl_username=
sasl_sender=
ccert_subject=
ccert_issuer=
ccert_fingerprint=Antwort:
action=DEFER_IF_PERMIT Greylisted, see http://postgrey.schweikert.ch/help/net.de.htmlGeht also nicht 
Hallo Forum,
ich habe bei einem Server Postfix, Dovecot und Postgrey im Einsatz.
Greylisting funktioniert auch super - nur wenn ich jetzt über IMAP eine Mail sende bekomme ich selber natürlich auch plötzlich einen '4.2.0: Recipient address rejected: Greylisted'.
Ich könnte jetzt meinen Absender Whitelisten - aber wenn ich das richtig sehe geht es hier nur um die IP-Adresse des Computers.
Wenn ich also 15 computer habe die alle meine Mails von @example.com absenden müsste ich die alle whitelisten?
Wie löst man das? So außergewöhnlich ist doch die Anforderung nicht, denke ich.
Thomas
Hier ein Benchmark des Root-Server XL SSD v6:
# # # # # # # ##### ###### # # #### # #
# # ## # # # # # # # ## # # # # #
# # # # # # ## ##### ##### # # # # ######
# # # # # # ## # # # # # # # # #
# # # ## # # # # # # # ## # # # #
#### # # # # # ##### ###### # # #### # #
Version 5.1.3 Based on the Byte Magazine Unix Benchmark
Multi-CPU version Version 5 revisions by Ian Smith,
Sunnyvale, CA, USA
January 13, 2011 johantheghost at yahoo period com
1 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10
1 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10
1 x Execl Throughput 1 2 3
1 x File Copy 1024 bufsize 2000 maxblocks 1 2 3
1 x File Copy 256 bufsize 500 maxblocks 1 2 3
1 x File Copy 4096 bufsize 8000 maxblocks 1 2 3
1 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10
1 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10
1 x Process Creation 1 2 3
1 x System Call Overhead 1 2 3 4 5 6 7 8 9 10
1 x Shell Scripts (1 concurrent) 1 2 3
1 x Shell Scripts (8 concurrent) 1 2 3
8 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10
8 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10
8 x Execl Throughput 1 2 3
8 x File Copy 1024 bufsize 2000 maxblocks 1 2 3
8 x File Copy 256 bufsize 500 maxblocks 1 2 3
8 x File Copy 4096 bufsize 8000 maxblocks 1 2 3
8 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10
8 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10
8 x Process Creation 1 2 3
8 x System Call Overhead 1 2 3 4 5 6 7 8 9 10
8 x Shell Scripts (1 concurrent) 1 2 3
8 x Shell Scripts (8 concurrent) 1 2 3
========================================================================
BYTE UNIX Benchmarks (Version 5.1.3)
System: hedgehog: GNU/Linux
OS: GNU/Linux -- 4.4.0-22-generic -- #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016
Machine: x86_64 (x86_64)
Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
CPU 0: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz (4594.7 bogomips)
x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
CPU 1: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz (4594.7 bogomips)
x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
CPU 2: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz (4594.7 bogomips)
x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
CPU 3: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz (4594.7 bogomips)
x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
CPU 4: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz (4594.7 bogomips)
x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
CPU 5: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz (4594.7 bogomips)
x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
CPU 6: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz (4594.7 bogomips)
x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
CPU 7: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz (4594.7 bogomips)
x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
07:06:02 up 9:49, 1 user, load average: 0.60, 0.38, 0.20; runlevel 5
------------------------------------------------------------------------
Benchmark Run: Tue Jun 07 2016 07:06:02 - 07:33:55
8 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 27801849.7 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2031.8 MWIPS (10.0 s, 7 samples)
Execl Throughput 2694.5 lps (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 978881.4 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 260401.4 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 2563582.1 KBps (30.0 s, 2 samples)
Pipe Throughput 1902016.4 lps (10.0 s, 7 samples)
Pipe-based Context Switching 88771.6 lps (10.0 s, 7 samples)
Process Creation 7000.3 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 8729.8 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 3421.5 lpm (60.0 s, 2 samples)
System Call Overhead 2994580.7 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 27801849.7 2382.3
Double-Precision Whetstone 55.0 2031.8 369.4
Execl Throughput 43.0 2694.5 626.6
File Copy 1024 bufsize 2000 maxblocks 3960.0 978881.4 2471.9
File Copy 256 bufsize 500 maxblocks 1655.0 260401.4 1573.4
File Copy 4096 bufsize 8000 maxblocks 5800.0 2563582.1 4420.0
Pipe Throughput 12440.0 1902016.4 1529.0
Pipe-based Context Switching 4000.0 88771.6 221.9
Process Creation 126.0 7000.3 555.6
Shell Scripts (1 concurrent) 42.4 8729.8 2058.9
Shell Scripts (8 concurrent) 6.0 3421.5 5702.5
System Call Overhead 15000.0 2994580.7 1996.4
========
System Benchmarks Index Score 1365.1
------------------------------------------------------------------------
Benchmark Run: Tue Jun 07 2016 07:33:55 - 08:01:52
8 CPUs in system; running 8 parallel copies of tests
Dhrystone 2 using register variables 216035838.5 lps (10.0 s, 7 samples)
Double-Precision Whetstone 16284.0 MWIPS (9.9 s, 7 samples)
Execl Throughput 18693.7 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 897355.6 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 233169.1 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 2755703.7 KBps (30.0 s, 2 samples)
Pipe Throughput 14829562.9 lps (10.0 s, 7 samples)
Pipe-based Context Switching 1086115.5 lps (10.0 s, 7 samples)
Process Creation 32522.4 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 37433.5 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 5312.4 lpm (60.0 s, 2 samples)
System Call Overhead 6298446.8 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 216035838.5 18512.1
Double-Precision Whetstone 55.0 16284.0 2960.7
Execl Throughput 43.0 18693.7 4347.4
File Copy 1024 bufsize 2000 maxblocks 3960.0 897355.6 2266.0
File Copy 256 bufsize 500 maxblocks 1655.0 233169.1 1408.9
File Copy 4096 bufsize 8000 maxblocks 5800.0 2755703.7 4751.2
Pipe Throughput 12440.0 14829562.9 11920.9
Pipe-based Context Switching 4000.0 1086115.5 2715.3
Process Creation 126.0 32522.4 2581.1
Shell Scripts (1 concurrent) 42.4 37433.5 8828.6
Shell Scripts (8 concurrent) 6.0 5312.4 8854.0
System Call Overhead 15000.0 6298446.8 4199.0
========
System Benchmarks Index Score 4638.2Ich habe eher den Eindruck dass die Mitbewerber gerne ein Geheimnis drum machen welche Virtualisierungstechnik sie überhaupt verwenden - geschweige denn ob der Core jetzt dediziert oder virtuell ist.
So genau unterscheiden das die wenigsten!
Thomas
@uerschlaeger:
Felix meinte ja dass die SSDs Platzmäßig sowieso nie ausgenutzt werden - deswegen wohl die kleinere SSD.
Und was bei den neuen Servern besser sein soll ist ja nicht nur der RAM sondern auch die CPU.
Es soll ja tatsächlich eine leistungsfähigere CPU (samt drumrum) drinstecken.
Ich persönlich finde die neuen Server aber auch nicht so attraktiv. Recht teuer und (zumindest auf den ersten Blick!) nicht wirklich mehr Leistung für mehr Geld.
Ist aber meine persönliche Meinung und wahrscheinlich werden Benchmarks schon beweisen dass die neuen Server auch ordentlich mehr Dampf haben.
Thomas
Und schon reicht dem ersten sein /64-Subnet nicht.
Verständlich, so schnell schaut man garnicht und schon hat man allen 18.446.744.073.709.551.615 Computern eine IP-Adresse gegeben
*scnr*
Thomas
Was ist denn die Meldung und die betroffene Zeile beim Import?
Thomas
Hallo Real-DD-2,
ich denke keiner wird dir das 100% bestätigen. Zuviel kann schief gehen.
Theoretisch geht es - meinem Verständnis nach!
Thomas
Deshalb muss wohl dein Nutzer in der Gruppe www-data sein und diese Gruppe muss Schreibrechte für den Ordner haben.
So würde ich das wohl wahrscheinlich probieren.
Im Zweifelfsall mal in die Logs von vsftp schauen ob da noch was steht.
Thomas
Wenn der Ordner schon existiert dann solltest du die Rechte des Ordners nicht anpassen.
Du kannst aber eventuell den neuen User in die Gruppe www-data stecken.
Das Problem hier ist dass ich dir gerne genau helfe wenn ich exakt weiß was du tust und willst (und damit auch weiß welche Rechte und Besitzer der Ordner hat).
Darauf kann man in einem Tutorial schlecht eingehen, und deshalb ist so ein Tutorial immer ein Ansatz um einem Admin zu helfen in die richtige Richtung zu kommen - die Details (also z.B. die Rechtevergabe der User auf deinem System) hängen zu sehr vom Einzelfall ab.
Ich gehe aber davon aus dass das jeder Administrator dann richtig einrichten kann.
Wenn du Hilfe brauchst probier ich dir gerne zu helfen.
Es kann natürlich sein dass vsftpd den Login nur in einen Ordner erlaubt der dem User gehört oder ähnliche Späßchen. Da helfen dann nur Forschungen im Logfile des vsftpd.
Nichts für ungut, aber es ist natürlich ein Unterschied ob du "einen FTP Server auf einem ansonsten leeren System installieren" willst, oder ob du "einen FTP Server auf einem Produktivsystem welches schon 5 Jahre läuft brauchst um vorhandene Dateien zu verändern"...
Thomas
Im Regelfall ist der Apache damit zufrieden dass er Lese-Rechte hat.
Hast du denn den Ordner neu angelegt für den neuen Nutzer?
Wenn du einen schon vorhandenen Nutzer nimmst dann solltest du nicht einfach so "chown" drüber klatschen - nur bei einem neuen.
Eventuell ist bei Netcup IPv6 standardmäßig aktiviert?
Jedenfalls ist es bei vielen Providern so (auch bei S t r a t o) dass man IPv6 erst aktivieren muss, und danach die zugeteilte Adresse statisch eintragen muss.
Warum da kein DHCPv6 oder die coolen neuen Features wie Router Advertisment oder so genutzt werden verstehe ich auch nicht.
Ich denke aber netcup wird schon wissen was sie tun - die anderen vermutlich auch. Mal abgesehen von s t r a t o - die wissen es garantiert nicht
Thomas
Dann hoffe ich mal dass dir diese Anleitung nun taugt. Ich denke ich hab sie aufs minimalst-nötigste runtergebrochen.
Die Anleitung ist übrigens unter Ubuntu 16.04 getestet.
Unter Ubuntu 14.04 (da hatte ich sie zuerst verfasst) war das mit dem deaktivieren des pam-moduls zum prüfen der shell noch nicht nötig.
Kommst du nun damit klar?
Brauchst du Hilfe?
Thomas
argh, die adresse stimmt auch nicht.
Es muss so heißen:
2a03:4000:6:5170::1Das "/64" bezeichnet sie Subnet-Maske, die haben wir unten schon mit "netmask 64" angegeben.
Im VCP steht die Schreibweise mit /64 weil man dir damit sagen will dass deinem Server die untersten 64 Bit der Adresse quasi frei gehören.
Du kannst also die IPv6 Adresse ab "2a03:4000:6:5170" wählen wie du willst.
Da ich gerne mit 1 anfange habe ich ":1" bei mir gewählt, aber die Adresse "2a03:4000:6:5170:0:dead:beef:cafe" oder "2a03:4000:6:5170:1234:5678:1234:5678" wäre auch valide
Thomas
PS: Sorry, wenn man Beiträge mit dem Handy schreibt um möglichst schnell zu helfen verhaut man gerne mal die Details...
Auf Wunsch eines einzelnen Users also hier noch die Erweiterung wir man aus dem obigen Plain FTP (was zum Testen und aus Kompatibilitätsgründen durchaus sinnvoll ist) ein verschlüsseltes FTP macht.
(ich denke ich hatte bei meinem letzten Versuch hier evtl. Probleme mit der Firewall - bei meinem jetzigen Test ging es auf Anhieb!)
Erstmal ein Zertifikat erstellen:
openssl req -x509 -nodes -days 3650 -newkey rsa:1024 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem
(die eingegebenen Daten sind eigentlich egal, werden aber eventuell dem Anwender beim ersten FTP Login gezeigt!
-> Die Gültigkeit ist hier auf 3650 Tage eingestellt, die sollte man natürlich "sinnvoll" wählen!)
Und dieses in der Datei '/etc/vsftpd.conf' eintragen, bzw. folgende Parameter anpassen:
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=YESNun noch den vsftpd neu starten:
service vsftpd restartJetzt sollte man sich per FTP (mit TLS) verbinden können.
Detaileinstellung:
(FileZilla)
User: mywebsite
Pass: xxx
Port: 21
Type: Require explicit FTP over TLS
(Plain FTP geht nun nicht mehr!)
Noch eine Erweiterung zur oberen Anleitung:
-> Achtung: Am Ende von "allow_writeable_chroot=YES" darf kein leerzeichen stehen, sonst startet der vsftpd nicht!
--> Wenn man ihn manuell mit '/usr/sbin/vsftpd' starten will kommt die Meldung "500 OOPS: bad bool value in config file for: allow_writeable_chroot"
Es war also nicht die Leerzeile nötig, sondern das Problem war ein Leerzeichen hinter dem "YES" - narf, da muss man erstmal drauf kommen!
Mit 'sftp' im oberen Beitrag meine ich natürlich "ftp" über den sshd.
Also:
Sind mir die Daten und die Passwörter nicht wichtig, aber einfachheit und kompatibilität dann nehme ich plain ftp.
Sind mir aber die Passwörter und Daten wichtig nehme ich sftp ("ftp" über den sshd), traue ich dem user nicht so muss halt ein chroot eingerichtet werden.
Ich habe schon oft beim Übertragen von weniger wichtigen Dateien mit Problem von Ftps (ftp mit tls) kämpfen müssen - das spare ich mir gerne, und der versuch vsftp mit ssl auf anhieb zum laufen zu bringen (was kein problem mit apache, dovecot oder postfix war) scheiterte. Das stärkte mich in der Vermutung dass am Ende vsftp total sicher gegen (imho nicht wirklich häufige) mitm attacken ist, ich aber dafür ärger mit programm xy oder zy haben werde. Deshalb also plain. Ich bin mir der Gefahren bewusst und erwarte dass jeder andere Serveradmin das auch weiß.
Das der FTP-User für plain ftp natürlich ein "unwichtiges" Passwort hat und die Daten egal sind sollte trotzdem klar sein.
Übrigens denke ich dass das auch der Grund ist warum netcup plain ftp erlaubt. Es ist einfach einfacher!
Thomas