Fetchmail und abholen der Mails von einem Provider

padersuse · 5 Sep. 2019

Mir ist ein gedanklicher Fehler unterlaufen :
Ich hatte die Doku zu dovecot so verstanden, dass /etc/dovecot/users ein Verzeichnis ist, in dem man die Datei passwd-file anlegen muss mit den Einträgen für die einzelnen User. War natürlich falsch, habe in der Datei users nach folgender Syntax meinen virtuellen User eingetragen

Code:

#syntax: username:passwort:uid:gid:home:realname:extra_fields

jetzt klappt es auch mit der Abfrage

Code:

doveadm user user@meinedomain.de

:

Code:

doveadm user user@meinedomain.de
field   value
uid     10000
gid     10000
home    /srv/vmail
mail    maildir:~/Maildir

abgdf · 5 Sep. 2019

Siehstewohl.

padersuse · 6 Sep. 2019

Hallo abgdf,

ist nett von Dir, dass Du soviel Geduld mit mir hast.
weisst Du, wie ich den lmtp Socket mit fetchmail ansteuere und sind wirklich 2 Anweisungen pro poll Anweisung notwendig, denn der lmtp Socket läuft lokal auf dem Rechner; und kann man sowohl die Anweisung

Code:

include auth-passwdfile.conf.ext

als auch die Anweisung

Code:

!include auth-system.conf.ext

in der Datei 10-auth.conf aktivieren ?

Habe folgenden Eintrag in der Datei 10-master.conf gemacht :

Code:

service lmtp {
  unix_listener lmtp {
    #mode = 0666
  }

  # Create inet listener only if you can't use the above UNIX socket
  inet_listener lmtp {
   # Avoid making LMTP visible for the entire internet
   address = 127.0.0.1
   port = 24
  }
}

Der lmtp socket läuft :

Code:

lsof -i :24
COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
dovecot 28839 root   30u  IPv4 2067815      0t0  TCP localhost:24 (LISTEN)

War inzwischen im Forum für Kakteen-Züchter nach Vorschlag von Gräfin Klara, aber die konnten mir auch nicht weiterhelfen, deswegen wende ich mich wieder vertauensvoll an Euch

padersuse · 14 Juli 2020

Es ist mir nun gelungen, dank Eurer Hinweise, mit fetchmail meine Emails über den Port 24 von dovecot abzuholen, wobei ich mit folgendem Eintrag in der .fetchmailrc arbeite :

Code:

poll pop3.strato.de proto POP3 user meine@email_adresse password meinpasswort smtphost 127.0.0.1/24,/var/spool/postfix/private/dovecot-lmtp smtpname vmail@germlin1.apopader.site is "meine@email_adresse"

        ssl
        sslfingerprint "F4:4E:FF:84:3B:DA:29:13:8F:4E:18:3A:E0:27:FD:63"
        sslcertck
        sslcertpath /etc/ssl/certs/

Habe dafür in der Datei /etc/dovecot/conf.d./10-master.conf folgenden Eintrag darstellen müssen :

Code:

service lmtp {
    unix_listener /var/spool/postfix/private/dovecot-lmtp {
#   unix_listener lmtp {
    #mode = 0666
  }

Gräfin Klara hatte das schon sehr schön dargestellt, ich hatte aber Probleme mit der Umsetzung. Jetzt kann ich alle Mails in einem Verzeichnis meiner Wahl, auf jeden Fall nicht im Home-Verzeichnis eines Users, ablegen. Vorteilhaft ist, dass ich in der Datei /etc/dovecot/users Emailadressen nennen kann, die nicht lokale User sind, aber zur Authentifizierung herangezogen werden können.
Leider habe ich noch ein Fehlermeldung im Log von fetchmail :

Code:

fetchmail: SMTP< 500 5.5.1 Unknown command

Code:

Trying to connect to 127.0.0.1/24...connected.
fetchmail: SMTP< 220 germlin1.apopader.site Dovecot ready.
fetchmail: SMTP> EHLO germlin1.apopader.site
fetchmail: SMTP< 500 5.5.1 Unknown command
Trying to connect to 127.0.0.1/24...connected.
fetchmail: SMTP< 220 germlin1.apopader.site Dovecot ready.
fetchmail: SMTP> HELO germlin1.apopader.site
[b]fetchmail: SMTP< 500 5.5.1 Unknown command[/b]
fetchmail: LMTP< 220 germlin1.apopader.site Dovecot ready.
fetchmail: LMTP> LHLO germlin1.apopader.site
fetchmail: LMTP< 250-germlin1.apopader.site
fetchmail: LMTP< 250-8BITMIME
fetchmail: LMTP< 250-CHUNKING
fetchmail: LMTP< 250-ENHANCEDSTATUSCODES
fetchmail: LMTP< 250-PIPELINING
fetchmail: LMTP< 250-STARTTLS
fetchmail: LMTP< 250 VRFY
fetchmail: forwarding to /var/spool/postfix/private/dovecot-lmtp
fetchmail: LMTP> MAIL FROM:<meine@email_adresse> BODY=8BITMIME
fetchmail: LMTP< 250 2.1.0 OK
fetchmail: LMTP> RCPT TO:<meine@email_adresse>
fetchmail: LMTP< 250 2.1.5 OK
fetchmail: LMTP> DATA
fetchmail: LMTP< 354 OK
#************
fetchmail: LMTP>. (EOM)
fetchmail: LMTP< 250 2.0.0 <meine@email_adresse> Uwl6MMxpDV+SUQAAzFkobA Saved
 flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< +OK Message 1 deleted
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Closing connection
fetchmail: LMTP> QUIT
fetchmail: LMTP< 221 2.0.0 Bye
fetchmail: 6.3.26 querying pop3.strato.de (protocol POP3) at Tue Jul 14 10:16:12 2020: poll completed
New UID list from pop3.strato.de: <empty>
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: normal termination, status 0

Kennt jemand den Grund für die Meldung

Code:

fetchmail: SMTP< 500 5.5.1 Unknown command

, vielleicht habe ich noch einen Fehler in der Datei /etc/dovecot/conf.d/10-master.conf drin; brauche ich den Eintrag inet_listener lmtp ? Aber klappt dann der lmtp-Transport über Port 24 noch, denn ich möchte Dovecot direkt ansteuern über Port 24

Code:

service lmtp {
    unix_listener /var/spool/postfix/private/dovecot-lmtp {
#   unix_listener lmtp {
    #mode = 0666
  }

  # Create inet listener only if you can't use the above UNIX socket
  inet_listener lmtp {
   # Avoid making LMTP visible for the entire internet
   address = 127.0.0.1
   port = 24
  }
}

spoensche · 14 Juli 2020

Dovecot arbeitet nicht auf Port 24. Als IMAP Server auf Port 143 bzw. mit SSL 993. Wenn du den LMTP über einen Unix Socket betreibst, dann brauchst du den Inet Listener nicht. Du kannst die beiden Listener auskommentieren und Dovecot verwendet dann automatisch den Unix Socket.

padersuse · 15 Juli 2020

Hallo Spoensche,
im Dovecot-Log sehe ich, dass mit Dovecot über den Port 24 eine Verbindung aufgebaut wird. Das EHLO, HELO bzw. LHLO wird ausgehandelt.

Code:

Trying to connect to 127.0.0.1/24...connected.
fetchmail: SMTP< 220 germlin1.apopader.site Dovecot ready.
fetchmail: SMTP> EHLO germlin1.apopader.site
fetchmail: SMTP< 500 5.5.1 Unknown command
Trying to connect to 127.0.0.1/24...connected.
fetchmail: SMTP< 220 germlin1.apopader.site Dovecot ready.
fetchmail: SMTP> HELO germlin1.apopader.site
[b]fetchmail: SMTP< 500 5.5.1 Unknown command[/b]
fetchmail: LMTP< 220 germlin1.apopader.site Dovecot ready.

im Buch Dovecot von Peer Heinlein empfiehlt der Autor das Protokoll zur Weiterleitung an Dovecot lmtp, da in Log-Dateien mehr Informationen stehen. Weiterhin empfiehlt er, wenn möglich. nicht dovecot-deliver sondern dovecot-lmtp als Transportmethode zu benutzen. Ich hab schon versucht bei Benutzung des Programms getmail lmtp einzusetzen, es hat aber nur mit getmail deliver funktioniert. Wenn ich einen unix-socket mit lmtp in der 10-master.conf Datei zur Verfügung stelle, funktioniert fetchmail leider nur durch Aufruf des Ports 24, also smtpname 127.0.0.1/24, pfad_zum_unix_socket, oder ich habe andere Möglichkeiten nicht gesehen.

Gräfin Klara · 15 Juli 2020

Bis heute ist unbekannt, wie dovecot von dir konfiguriert wurde.
Arbeitet dovecot als imap, pop3 oder maildir server.

padersuse · 16 Juli 2020

Als Imap-Server mit dem Speicherformat Maildir

Gräfin Klara · 16 Juli 2020

padersuse schrieb:
Als Imap-Server mit dem Speicherformat Maildir

Gute Wahl

padersuse schrieb:
vielleicht habe ich noch einen Fehler in der Datei /etc/dovecot/conf.d/10-master.conf ...

Diese Konfiguration ist unfertig, wahrscheinlich von irgendwo einfach abgeschrieben, deshalb auch die Probleme.
Ich stelle hier ein mailingsystem dar, bestehend aus den von dir verwendeten Komponenten.
Wenn du das verstehst, dann wird dir auch die gesamte Konfiguration klarer erscheinen.

Code:

                      +-----------+                  +---------+             +-------------+
                      | Fetchmail |                  | Dovecot |             | Thunderbird |
WEB >-----[1]--------->           >-------[2]--------> Maildir >----[3]------>  Empfang    |
                      |           |                  |         |             |             |
                      +-----------+                  +----+----+             |             |
                                                          |                  +-+         +-+
                            +----->-------[5]-------------+                    |         |   
                            |                                                +-+         +-+
                      +-----+-----+                                          |             |
                      |  Postfix  |                                          |             |
WEB <>----[4]--------<>           <-------[6]--------------------------------<   Senden    |
                      |           |                                          |             |
                      +-----------+                                          +-------------+

Erklärung: deine LAN Domain nennt sich padersuse.lan
Dein mailingsystem besteht bekannterweise aus den internen Komponenten Fetchmail, Dovecot und Postfix.
Diese 3 Komponenten sind alle über LMTP [2] und [5] miteinander verbunden. Dafür ist LMTP da.
Generell wird der Mailtransport unterschieden zwischen a. Abholen, b. Senden und c. Empfangen.

a. Abholen:
Fetchmail holt [1] mittles POP3 oder POP3S (SSL/TLS) oder POP3 (STARTTLS) von einem oder mehreren Server je nach Konfiguration alle mails ab und speichert sie zwischen. Wenn alles ok, markiert Fetchmail alle empfangenen mails mit dem flag "Neu Empfangen", baut eine LMTP-Verbindung [2] nach Dovecot auf und sendet sie dorthin.
Dovecot legt die mails im Format Maildir ab und sendet den IMAP_event "Neue Mails vorhanden" [3] nach allen Thunderbirds in deinem LAN. Schon werden die mails in den entsprechenden Ordern an allen Thunderbirds mittels IMAP angezeigt.

b. Senden
Thunderbird sendet [6] über SMTP nach Postfix. Postfix analysiert Sender- und Empfängeradresse. Wenn Senderadresse z.B. padersuse@gmx.com, dann steht in der Postfix Konfiguration auch der zuständige Server, z.B. mail.gmx.com. Postfix sendet [4] diese mail mittels SMTP also nach mail.gmx.com. Wenn das funktioniert hat, dann markiert Postfix eine Kopie dieser mail mit dem Marker "Gesendet" und sendet diese Kopie [5] über LMTP nach Dovecot. Wieder IMAP_events [3] nach allen Thunderbirds und die mail ist sofort sichtbar unter z.B. Folder "Gesendet".
Geht das Senden nach mail.gmx.com aber schief, sendet postfix eine Fehlermeldung [5] nach Dovecot an die Adresse z.B postmaster@padersuse.lan
Lautet die Empfängeradresse z.B. karl@padersuse.lan, dann sendet Postfix natürlich über [5] und nicht [4].
Es ist deshalb sehr wichtig, das deine Namensauflösung 100% funktioniert.
Test:
# hostname -s .... darf nur den hostname anzeigen. (z.B. mail)
# hostname -d ... nur den domainnamen (padersuse.lan)
# hostname -f ... full (mail.padersuse.lan)
Wenn das nicht funktioniert, wird dein mailingsystem nie funktionieren.

c. Empfangen
Über SMTP [4] können von außen mails empfangen werden und diese werden über LMTP [5] an Dovecot übergeben.
Das wirst du wahrscheinlich nicht benötigen.

An diesem Aufbau ist zu erkennen, wie vorteilhaft es ist, wenn das mailingsystem aus einzelnen Komponenten besteht und nicht aus einem Server, der alles kann. Den Variationen an Verschaltungen sind keine Grenzen gesetzt.

Wie du auch siehst, braucht es 2 LMTP Kanäle, die den Komponenten auch per Konfiguration bekannt sein müssen.
Beispiel für dovecot, wo beide Kanäle zusammenkommen:

Code:

service lmtp {
	unix_listener /var/spool/postfix/private/dovecot-lmtp {
		group = postfix
		user = postfix
		mode = 0600
	}
	unix_listener /var/spool/fetchmail/dovecot-lmtp {
		group = root
		user = fetchmail
		mode = 0600
	}
}

LMTP-Kanal [2] heißt /var/spool/fetchmail/dovecot-lmtp
LMTP-Kanal [5] heißt /var/spool/postfix/private/dovecot-lmtp
Natürlich muß der jeweilige Kanal auch Fetchmail und Postfix bekannt sein.
Ich glaube bei Fetchmail nennt sich der key smtphost.

Gruß
Gräfin Klara

spoensche · 17 Juli 2020

@GräfinKlara:

In deinem Beispiel, Fetchmail direkt zu Dovecot, gibt es keine adäquate Möglichkeit zum Spam Filtern und das wird in der Praxis so nicht umgesetzt.

Folgende Prozesskette beinhaltet auch die Möglichkeit für eine adäquate Spamfilterung:

Code:

Fetchmail -> Postfix -> Dovecot

Gräfin Klara · 17 Juli 2020

spoensche schrieb:
@GräfinKlara:

In deinem Beispiel, Fetchmail direkt zu Dovecot, gibt es keine adäquate Möglichkeit zum Spam Filtern ...

Das ist korrekt, Spam Filter hatte ich nicht bedacht.
@padersuse sollte deinen Hinweis berücksichtigen

Gruß

padersuse · 18 Juli 2020

Hallo Gräfin Klara,

dann wäre es wohl besser,mit fetchmail die Mails an postfix zu leiten, welcher dann an dovecot weiterleiten müsste. Wenn ich aber in die Datei .fetchmailrc unter smtpname nur 127.0.0.1 eintrage, wird postfix angesprochen, dovecot bleibt dann aber unangetastet und die Mail landet nicht im vorgesehenen Verzeichnis.
Was müsste ich dann ändern, damit das klappt ?
Gruß Padersuse

Gräfin Klara · 18 Juli 2020

padersuse schrieb:
Hallo Gräfin Klara,

dann wäre es wohl besser,mit fetchmail die Mails an postfix zu leiten, welcher dann an dovecot weiterleiten müsste.

Das ist eine Frage der Anforderungen, die du an dein mailingsystem stellst.

1. Wenn du keinen Spam Filter brauchst, dann realisiere fetchmail -> dovecot.

2. Wenn du Spam Filter willst, du dich aber mit der Funktionalität von Spam Filter nicht beschäftigen willst, dann verwende
fetchmail -> postfix -> dovecot

3. Wenn du Spam Filter willst, du dich damit auseinandersetzen möchtest UND alle IMAP Funktionalitäten von dovecot uneingeschränkt nutzen möchtest, realisiere fetchmail -> dovecot wie oben dargestellt und beschäftige dich mit "Dovecot Sieve Pigeonhole".

@spoensche schreibt dazu:

spoensche schrieb:
In deinem Beispiel, Fetchmail direkt zu Dovecot, gibt es keine adäquate Möglichkeit zum Spam Filtern und das wird in der Praxis so nicht umgesetzt.

Dieser Hinweis ist korrekt, trotzdem würde ich aus mehreren Gründen nicht daran festhalten. Da sich mit Dovecot Pigeonhole
ein hervorragender Spam Filter realisieren läßt, gibt es keinen Grund (nur wegen der Spams), die mails über Postfix umzuleiten. Das ist ein unnötiger Umweg. Dieser Umweg über Postfix schränkt sowohl das Routing ein, als auch das IMAP
von Dovecot. Dass in der Praxis dieser Umweg über Postfix genommen wird, hat eher historische Gründe und stammt aus einer Zeit, als Postfix das Zentrum des mailingsystems war und deshalb generell alle mails über Postfix geroutet wurden. Ich sehe das als überholt. Entscheiden mußt du aber selbst, es gibt dafür kein "Richtig" oder "Falsch".

padersuse schrieb:
Wenn ich aber in die Datei .fetchmailrc unter smtpname nur 127.0.0.1 eintrage, wird postfix angesprochen, dovecot bleibt dann aber unangetastet und die Mail landet nicht im vorgesehenen Verzeichnis.
Was müsste ich dann ändern, damit das klappt ?
Gruß Padersuse

Du willst ja über LMTP nach Dovecot senden, deshalb:
smtphost /var/spool/fetchmail/dovecot-lmtp
Siehe oben zu LMTP-Kanal [2]

Gruß
Gräfin Klara

spoensche · 18 Juli 2020

Gräfin[quote="Gräfin Klara schrieb:
Dieser Hinweis ist korrekt, trotzdem würde ich aus mehreren Gründen nicht daran festhalten. Da sich mit Dovecot Pigeonhole
ein hervorragender Spam Filter realisieren läßt, gibt es keinen Grund (nur wegen der Spams), die mails über Postfix umzuleiten. Das ist ein unnötiger Umweg. Dieser Umweg über Postfix schränkt sowohl das Routing ein, als auch das IMAP
von Dovecot. Dass in der Praxis dieser Umweg über Postfix genommen wird, hat eher historische Gründe und stammt aus einer Zeit, als Postfix das Zentrum des mailingsystems war und deshalb generell alle mails über Postfix geroutet wurden. Ich sehe das als überholt. Entscheiden mußt du aber selbst, es gibt dafür kein "Richtig" oder "Falsch".

Dafür gibt es kein "richtig" oder "falsch". Da stimme ich dir zu.

Mit Sieve Spamfilter umzusetzen passiert auf der Benutzerebene. Ein Spamfilter arbeitet am effektivsten global, also benutzerunabhängig.
Mit Sieve kannst du z.B auch keine NON-FQDN Sender aussortieren. Du kannst auch kein Greylisting, Milter, Sender Policy Framework (SPF), DKIM usw. verwenden. Du kannst so auch keinen ausgehenden (von intern nach extern) Spam-Versand unterbinden.

Also von effektiv und hervoragend kann man da nicht sprechen.

Nebenbei werden unnötige Resourcen verbraucht, wenn Spam nicht direkt am SMTP Server sondern erst am IMAP- Server gefiltert wird. Dovecot kann kein Mail- Routing.

Mir ist keine gängige Fachliteratur bekannt, in der Fetchmail direkt zu Dovecot weiterleitet.

Wie und wo schränkt Postfix den IMAP ein? Postfix macht nur SMTP.

padersuse · 19 Juli 2020

An Gräfin Klara und Spönsche,

an sich hatte ich folgendes vor :
Postfix nimmt über Port 25 alle Mails an,
für lokale user sind folgende Variablen in der main.cf wichtig :
$mydestination
$local_recipient_maps = passwd.byname
$mailbox_command = local

für user, die sich z.B. nur über die Email-Adresse authentifizieren sind folgende Einträge wichtig,
$relay_domains
reject_unverified_recipient
$transport_maps

bisher habe ich mit fetchmail die Mails ins Home-Verzeichnis der lokalen user geleitet mit "is user_andreas" here
da ich die Authentifizierung mit einer Email-Adresse mit Hilfe der Datei /etc/dovecot/users aber viel interessanter und sinniger finde, muss ich in der .fetchmailrc etwas ändern und/oder an den definierten Sockets. Ich kann mich ja immernoch entscheiden, ob ich die Emails direkt an dovecot mit fetchmail sende oder es anders mache. Ich habe nicht Euren Überblick und deswegen wird sich das zeigen.
in der Datei relay_domains habe ich folgendes eingetragen :

Code:

apopader.site   lmtp:[127.0.0.1]

Übrigens das Verzeichnis /var/spool/fetchmail/ muss ich erst noch anlegen, ich vermute als User root, Gruppe root.

Warum klappt das Abholen mit fetchmail mit dem Eintrag in der.fetchmailrc-Datei nicht mit

Code:

poll pop3.strato.de proto POP3 user willi@winzig.de password willi smtphost 127.0.0.1 smtpname vmail@germlin1.apopader.site is "willi@winzig.de"

spoensche · 20 Juli 2020

padersuse schrieb:
bisher habe ich mit fetchmail die Mails ins Home-Verzeichnis der lokalen user geleitet mit "is user_andreas" here
da ich die Authentifizierung mit einer Email-Adresse mit Hilfe der Datei /etc/dovecot/users aber viel interessanter und sinniger finde, muss ich in der .fetchmailrc etwas ändern und/oder an den definierten Sockets. Ich kann mich ja immernoch entscheiden, ob ich die Emails direkt an dovecot mit fetchmail sende oder es anders mache. Ich habe nicht Euren Überblick und deswegen wird sich das zeigen.
in der Datei relay_domains habe ich folgendes eingetragen :

Code:

apopader.site lmtp:[127.0.0.1]

Übrigens das Verzeichnis /var/spool/fetchmail/ muss ich erst noch anlegen, ich vermute als User root, Gruppe root.

Warum klappt das Abholen mit fetchmail mit dem Eintrag in der.fetchmailrc-Datei nicht mit

Code:

poll pop3.strato.de proto POP3 user willi@winzig.de password willi smtphost 127.0.0.1 smtpname vmail@germlin1.apopader.site is "willi@winzig.de"

Relay Domains werden nach aussen, also an einen anderen SMTP- Server gesendet. Da hat LMTP nichts verloren und das Protokoll LMTP kennt Postfix nicht.

Statt "is user andreas here" musst du die vollständige e-Mail Addresse angeben. "is user andreas@apopader.site" here. Dann leitet Fetchmail die e-Mail an den lokalen Postfix, der bei richtiger Konfiguration, die e-Mail an Dovecot weiterleitet, damit der sie in ein Postfach einsortiert. Die Authentifizierung nimmt Postfix über Dovecot vor, sofern die Postfix Konfiguration stimmt.

Gräfin Klara · 20 Juli 2020

spoensche schrieb:
Mit Sieve Spamfilter umzusetzen passiert auf der Benutzerebene. Ein Spamfilter arbeitet am effektivsten global, also benutzerunabhängig.
Mit Sieve kannst du z.B auch keine NON-FQDN Sender aussortieren. Du kannst auch kein Greylisting, Milter, Sender Policy Framework (SPF), DKIM usw. verwenden.

Dein mailingsystem ist zuständig für @yourdomain.com und nichts anderes. Die mail adressen an [1] liegen alle und ausnahmslos außerhalb deiner domain!! Ein mail von spoensche@gmx.com nach klarissa@gmail.com - und nur solche kommen über [1] herein, sollen weder über postfix laufen, noch geroutet werden und auch nicht gefiltert werden. Es gibt dafür keinen Grund. Alle mails an [1] sind geroutet, sie sind gefiltert und haben mit SMTP nichts zu tun. Als maximale Sicherheitsmaßnahme reicht Pigeonhole für das Entfernen bestimmter Attachments allemal. Mehr braucht es hier nicht. Siehe dazu die entsprechenden RFC für POP3 Server Anbieter, Beschreibung der jeweiligen Provider wie gmx, google und andere und von diesen Firmen eingesetzten SPAM Filter sowie die egress oder outbound filter Regeln dieser Provider, die EU-Regeln entsprechen müssen. Sollen diese mails nach postfix geroutet werden, um diese bereits gefilterten und gerouteten mails nocheinmal zu filtern und zu routen? Das ist nicht nur ein sinnloser overkill, es würde aus mehreren Gründen auch gar nicht funktionieren.

spoensche schrieb:
Du kannst so auch keinen ausgehenden (von intern nach extern) Spam-Versand unterbinden.

Was soll das? Selbstverständlich ist dieses mailingsystem für @yourdomain.com verantwortlich, sowohl für Senden als auch Empfang. Diese Verantwortung wird über [6], [4] auch wahrgenommen, egal ob @yourdomain.com Empfänger oder Sender ist. Dein System ist aber NICHT verantwortlich für gmx.com, gmail.com oder ähnlich.

spoensche schrieb:
Nebenbei werden unnötige Resourcen verbraucht, wenn Spam nicht direkt am SMTP Server sondern erst am IMAP- Server gefiltert wird.

Nocheinmal. Alle mails von oder nach @yourdomain.com laufen über Postfix.
Sie werden von Postfix geroutet, gefiltert und zugeteilt.
Dovecot übernimmt diese Aufgabe nicht.

spoensche schrieb:
Dovecot kann kein Mail- Routing.

Es braucht auf [1] kein routing, es gibt auf [1] kein SMTP und fremde domains für private Accounts werden in Postfix nicht verwaltet.
Es gibt keinen Grund, fremde domains (wenn Sender UND Empfänger fremde domain) über Postfix zu routen.
Diese mails sind Anwenderspezifisch, sie werden nur einem user fix zugeteilt, das wars.
Wo siehst du in meiner Zeichnung ein routing in Dovecot? Das gibt es nicht.

spoensche schrieb:
Wie und wo schränkt Postfix den IMAP ein? Postfix macht nur SMTP.

Ich habe nicht geschrieben, dass Postfix IMAP einschränkt, sondern das die unnötige Umleitung über Postfix IMAP enschränkt. Wie schon erwähnt, unterscheiden wir zwischen a.Abgeholt, b.Empfangen, c. Gesendet. Umleitung über Postfix. also SMTP, bedeutet das Ausscheiden von "Abgeholt", weil es nach SMTP geht und so in "Empfangen" geschrieben wird. Diese anwenderspezifischen, abgeholten mails stellen aber in "Empfangen" ein Sicherheitsrisiko dar, sie lassen sich mittels IMAP nicht mehr als "Abgeholt" einem sicheren und privaten Bereich zuteilen. Anwenderspezifische mails haben im Folder ~/Empfangen nichts zu suchen. In ~/Empfangen stehen mails für @yourdomain.com und sonst nichts. Die Trennung zwischen Anwenderspezifisch (Abgeholt über POP3) und @yourdomain.com (SMTP) ist für die Sicherheit essentiell, wird aber durch die Umleitung über Postfix ausgehebelt. Firma (@yourdomain.com) und privat sind strikt zu trennen, privat hat im Postfix (SMTP) nichts verloren!

Im Übrigen, selbstverständlich kann Postfix LMTP.
Postfix ist eine typische Komponente eines mailingsystems, LMTP ist obligatorisch für solche Komponenten.
http://www.opensource.apple.com/source/postfix/postfix-129/postfix/README_FILES/LMTP_README

spoensche schrieb:
Da hat LMTP nichts verloren und das Protokoll LMTP kennt Postfix nicht.

Warum schreibst du sowas?

Gruß
Gräfin Klara

padersuse · 22 Juli 2020

Ich danke Euch für Eure Beiträge, die es mir ermöglicht haben, mit fetchmail meine Mails vom Provider abzuholen und Dovecot zuzustellen über LMTP auf Port 24.
Gruß Padersuse

spoensche · 27 Juli 2020

Gräfin Klara schrieb:
Im Übrigen, selbstverständlich kann Postfix LMTP.
Postfix ist eine typische Komponente eines mailingsystems, LMTP ist obligatorisch für solche Komponenten.
http://www.opensource.apple.com/source/postfix/postfix-129/postfix/README_FILES/LMTP_README

spoensche schrieb:

Da hat LMTP nichts verloren und das Protokoll LMTP kennt Postfix nicht.

Zum Vergrößern anklicken....

Warum schreibst du sowas?

Mein Fehler, bin auch nur ein Mensch.

@Gräfin Klara

Woher nimmst du die Informationen, dass es sich um GMX, Web.de oder sonst etwas handelt?
Es handelt sich um die Domain winzig.de und ob dort Spamfilterung und Virenscan mit in dem Angebot sind ist unbekannt.

Gräfin Klara · 28 Juli 2020

spoensche schrieb:
Woher nimmst du die Informationen, dass es sich um GMX, Web.de oder sonst etwas handelt?
Es handelt sich um die Domain winzig.de und ob dort Spamfilterung und Virenscan mit in dem Angebot sind ist unbekannt.

Diese Frage verstehe ich nicht. Könntest du mir mit einem Beispiel auf die Sprünge helfen?