zweite Instanz mit eigenem Transport

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

zweite Instanz mit eigenem Transport

Ronny Seffner
Hallo Liste,

ich dachte mein Problem ist einfach zu Lösen.
Da ist ein funktionierender postfix, der die "lokalen"
Empfängerinformationen via virtual_ aus MySQL zieht. Zusätzlich holt ein
fetchmail noch ein paar fremde Postfächer ab und übergibt sie dem Postfix.
Nun kommt es hin und wieder vor, dass eine dieser mit fetchmail abzuholenden
Mails größer ist, als das gewollte message_size_limit des Postfix. Leider
kann nach meiner Kenntnis fetchmail damit nicht gut umgehen und versucht
diese Mails eben wieder und wieder erfolglos abzuholen.

Nun war meine Idee, in der master.cf einfach für einen weiteren smtpd zu
sorgen, der ein weniger strenges message_size_limit fährt. An diesen soll
fetchmail liefern. Nun soll diese zweite Instanz aber die Post der ersten
Instanz in die Hand drücken, bekommt das Limit zu spüren und erstellt dann
aber ein NDA an den ursprünglichen Absender (was fetchmail ja leider nicht
beherrscht). Mir ist klar, dass es technologisch sauberer wäre, diese
externen Postfächer würden schon entsprechend limitieren.

Was nun aber passiert, ist dass diese neue Instanz - egal wie ich es
konfiguriere - irgendwie den transport "dovecot" aus den virtual_*_maps der
main.cf "erbt" und nicht überschrieben bekommt. In der Dokumentation finde
ich auch keinen Hinweis, dass das nicht gehen soll.

postconf -n

compatibility_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
dovecot_destination_recipient_limit = 1
html_directory = no
inet_protocols = ipv4
local_transport = local
mailbox_size_limit = 0
mydomain = LOCALDOMAIN.TLD
mynetworks = 127.0.0.0/8, 192.168.2.0/24
mynetworks_style = subnet
relay_domains = $mydestination
relayhost = RELAY.DOMAIN2.TLD
sender_canonical_maps = hash:/etc/postfix/sender_canonical
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
smtp_sasl_security_options = noanonymous
smtp_tls_loglevel = 1
smtp_use_tls = yes
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unknown_client_hostname
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination, reject_unauth_pipelining,
reject_non_fqdn_recipient
smtpd_relay_restrictions =
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_login_maps =
mysql:/etc/postfix/mysql-virtual_sender_permissions.cf
smtpd_sender_restrictions = check_recipient_access
hash:/etc/postfix/recipient_access, check_sender_access
hash:/etc/postfix/sender_access, permit_mynetworks,
reject_sender_login_mismatch, permit_sasl_authenticated,
reject_unknown_helo_hostname, reject_unknown_recipient_domain,
reject_unknown_sender_domain,
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual_alias_maps.cf
virtual_gid_maps = static:2000
virtual_mailbox_base = /
virtual_mailbox_domains =
mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf
virtual_mailbox_limit = 0
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual_mailbox_maps.cf
virtual_transport = dovecot
virtual_uid_maps = static:2000


die oben genutzte transport map

DOMAIN.TLD        :[127.0.0.1]


und der entscheidende Teil in der master.cf

127.0.0.1:26 inet n      -       y       -       -       smtpd
  -o message_size_limit=102400000
  -o virtual_transport=
  -o virtual_mailbox_maps=
  -o virtual_mailbox_domains=
  -o virtual_alias_maps=
  -o relayhost=[127.0.0.1]


Immer wenn ich an 127.0.0.1 ein Mail für DOMAIN.TLD abgebe, geht die nicht
an den 127.0.0.1:25 und hat im Log "relay=dovecot".
Wie kann ich denn erzwingen, dass der smtpd an 127.0.0.1:26 alles versucht
an den smtpd an 127.0.0.1:25 zu geben oder alternativ zu bouncen?


Mit freundlichen Grüßen / Kind regards
     Ronny Seffner


Reply | Threaded
Open this post in threaded view
|

Re: zweite Instanz mit eigenem Transport

S. Kremer
Hi,

fetchmail kennt die beiden Optionen:
--limit
--limitflush
damit kann man vermeiden, dass zu große Mails abgerufen werden und auf dem Server gelöscht werden.
zum anderen kann man über die Option
--smtphost
Mails direkt dem Postfix zustellen, auch auf einem anderen Port

https://www.fetchmail.info/fetchmail-man.html#10

Gruß
Stefan

--- Original Nachricht ---
Betreff: zweite Instanz mit eigenem Transport
Von: "Ronny Seffner" <[hidden email]>
An: [hidden email]
Datum: 14-05-2020 18:18



Hallo Liste,

ich dachte mein Problem ist einfach zu Lösen.
Da ist ein funktionierender postfix, der die "lokalen"
Empfängerinformationen via virtual_ aus MySQL zieht. Zusätzlich holt ein
fetchmail noch ein paar fremde Postfächer ab und übergibt sie dem Postfix.
Nun kommt es hin und wieder vor, dass eine dieser mit fetchmail abzuholenden
Mails größer ist, als das gewollte message_size_limit des Postfix. Leider
kann nach meiner Kenntnis fetchmail damit nicht gut umgehen und versucht
diese Mails eben wieder und wieder erfolglos abzuholen.

Nun war meine Idee, in der master.cf einfach für einen weiteren smtpd zu
sorgen, der ein weniger strenges message_size_limit fährt. An diesen soll
fetchmail liefern. Nun soll diese zweite Instanz aber die Post der ersten
Instanz in die Hand drücken, bekommt das Limit zu spüren und erstellt dann
aber ein NDA an den ursprünglichen Absender (was fetchmail ja leider nicht
beherrscht). Mir ist klar, dass es technologisch sauberer wäre, diese
externen Postfächer würden schon entsprechend limitieren.

Was nun aber passiert, ist dass diese neue Instanz - egal wie ich es
konfiguriere - irgendwie den transport "dovecot" aus den virtual_*_maps der
main.cf "erbt" und nicht überschrieben bekommt. In der Dokumentation finde
ich auch keinen Hinweis, dass das nicht gehen soll.

postconf -n

compatibility_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
dovecot_destination_recipient_limit = 1
html_directory = no
inet_protocols = ipv4
local_transport = local
mailbox_size_limit = 0
mydomain = LOCALDOMAIN.TLD
mynetworks = 127.0.0.0/8, 192.168.2.0/24
mynetworks_style = subnet
relay_domains = $mydestination
relayhost = RELAY.DOMAIN2.TLD
sender_canonical_maps = hash:/etc/postfix/sender_canonical
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
smtp_sasl_security_options = noanonymous
smtp_tls_loglevel = 1
smtp_use_tls = yes
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unknown_client_hostname
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination, reject_unauth_pipelining,
reject_non_fqdn_recipient
smtpd_relay_restrictions =
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_login_maps =
mysql:/etc/postfix/mysql-virtual_sender_permissions.cf
smtpd_sender_restrictions = check_recipient_access
hash:/etc/postfix/recipient_access, check_sender_access
hash:/etc/postfix/sender_access, permit_mynetworks,
reject_sender_login_mismatch, permit_sasl_authenticated,
reject_unknown_helo_hostname, reject_unknown_recipient_domain,
reject_unknown_sender_domain,
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual_alias_maps.cf
virtual_gid_maps = static:2000
virtual_mailbox_base = /
virtual_mailbox_domains =
mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf
virtual_mailbox_limit = 0
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual_mailbox_maps.cf
virtual_transport = dovecot
virtual_uid_maps = static:2000


die oben genutzte transport map

DOMAIN.TLD        :[127.0.0.1]


und der entscheidende Teil in der master.cf

127.0.0.1:26 inet n      -       y       -       -       smtpd
  -o message_size_limit=102400000
  -o virtual_transport=
  -o virtual_mailbox_maps=
  -o virtual_mailbox_domains=
  -o virtual_alias_maps=
  -o relayhost=[127.0.0.1]


Immer wenn ich an 127.0.0.1 ein Mail für DOMAIN.TLD abgebe, geht die nicht
an den 127.0.0.1:25 und hat im Log "relay=dovecot".
Wie kann ich denn erzwingen, dass der smtpd an 127.0.0.1:26 alles versucht
an den smtpd an 127.0.0.1:25 zu geben oder alternativ zu bouncen?


Mit freundlichen Grüßen / Kind regards
     Ronny Seffner

logo_ik.png (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: zweite Instanz mit eigenem Transport

Michael Grundmann-2
Am 14.05.20 um 19:30 schrieb GMX Account:

Hallo,

> Hi,
>
> fetchmail kennt die beiden Optionen:
> --limit
> --limitflush
> damit kann man vermeiden, dass zu große Mails abgerufen werden und auf
> dem Server gelöscht werden.

und damit ist die Mail aber mit 200 angenommen worden und wird rückwärts
"still" gelöscht?

> zum anderen kann man über die Option
> --smtphost
> Mails direkt dem Postfix zustellen, auch auf einem anderen Port
>

wird hier eine Meldung an den Versender gesendet?

Ich kenne mich mit fetchmail überhaupt nicht mehr aus - das habe ich vor
Jahrzehnten mal genutzt


--
Gruß Michael

Wenn du verstehst, was du tust, wirst du nichts lernen
BTW: Produktionsbremsen sind immer die Bürokraten
Reply | Threaded
Open this post in threaded view
|

AW: zweite Instanz mit eigenem Transport

Ronny Seffner
In reply to this post by S. Kremer
Hallo Stefan,

> fetchmail kennt die beiden Optionen:
> --limit
> --limitflush
>
Richtig. Dann holt er nicht ab, die Mail bleibt im "ersten" Briefkasten. Der Absender glaubt an Zustellung und der Empfänger weiß von nix. Darum will ich bouncen/ein NDA und DAS kann fetchmail wohl nicht.

> --smtphost
> Mails direkt dem Postfix zustellen, auch auf einem anderen Port
>
Korrekt, dass will ich verwenden, damit fetchmail an die Instanz auf 127.0.01:26 abgibt. Meine Frage zielt also weiterhin auf postfix.

Trotzdem danke für Deine Zeit.


Mit freundlichen Grüßen / Kind regards
     Ronny Seffner

Reply | Threaded
Open this post in threaded view
|

AW: zweite Instanz mit eigenem Transport

Ronny Seffner
In reply to this post by Michael Grundmann-2
Hallo Michael,

> und damit ist die Mail aber mit 200 angenommen worden und wird rückwärts
> "still" gelöscht?
>
Eine etwas übertriebene Beschreibung, bzw. hast Du recht, wenn man dem fetchmal noch sagt, dass es alles was es sieht auch löschen soll - egal ob abgeholt oder nicht.

> > --smtphost
> > Mails direkt dem Postfix zustellen, auch auf einem anderen Port
>
> wird hier eine Meldung an den Versender gesendet?
>
Eben leider nicht, nur ins Log.

Vielleicht hätte ich Vorgeschichte und Zusammenhänge weglassen sollen, damit "man" sich mehr auf das postfix-Problem konzentriert: warum kann ich in der 127.0.01:26er Instanz dieses dovecot-Ziel nicht überschreiben?



Mit freundlichen Grüßen / Kind regards
     Ronny Seffner

Reply | Threaded
Open this post in threaded view
|

Re: zweite Instanz mit eigenem Transport

Markus Winkler
Hallo Ronny,

On 15.05.20 16:06, Ronny Seffner wrote:
>
> damit "man" sich mehr auf das postfix-Problem konzentriert: warum kann ich in der 127.0.01:26er Instanz dieses dovecot-Ziel nicht überschreiben?

weil Du das m. W. beim smtpd nicht kannst - ich hoffe, ich erzähle da nix
Falsches:

Du hast

> virtual_transport = dovecot

und das gilt global für alle bei

> virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf

gelisteten Domains.

Entscheidend dabei ist trivial-rewrite, und dafür kann man, so ist
jedenfalls mein Kenntnisstand, keine zusätzlichen Einstellungen vornehmen
bzw. vorhandene überschreiben.

Aber mal abgesehen davon: Selbst wenn das

> Wie kann ich denn erzwingen, dass der smtpd an 127.0.0.1:26 alles versucht
> an den smtpd an 127.0.0.1:25 zu geben oder alternativ zu bouncen?

ginge, dann hättest Du ja im Endeffekt nur dieses Ziel erreicht, richtig?:

> bekommt das Limit zu spüren und erstellt dann
> aber ein NDA an den ursprünglichen Absender

Wäre das wirklich der einzige Sinn und Zweck des ganzen Unterfangens? Oder
verstehe ich das falsch?

Weitere Frage:

> Nun kommt es hin und wieder vor, dass eine dieser mit fetchmail abzuholenden
> Mails größer ist, als das gewollte message_size_limit des Postfix.

Ist dieses message_size_limit von Dir generell so gewollt oder soll für den
Empfangsweg via fetchmail ggf. eine Ausnahme gemacht werden?

Wenn keine Ausnahme: Was passiert dann eigentlich mit den zu großen Mails?
Die sind ja irgendwo schon mal eingeliefert worden, und der ursprüngliche
Absender denkt, dass der Empfänger die Mail schon längst in seiner Inbox hat.

Wenn jedoch dafür eine Ausnahme erlaubt sein soll: Hattest Du schon mal
überlegt, die Mails von fetchmail (an Postfix vorbei) direkt an Dovecot zu
übergeben? Nur so als Gedanke, habe ich selber noch nicht genutzt.

Viele Grüße
Markus
Reply | Threaded
Open this post in threaded view
|

AW: zweite Instanz mit eigenem Transport

Ronny Seffner
Hallo Markus,

> Entscheidend dabei ist trivial-rewrite, und dafür kann man, so ist
> jedenfalls mein Kenntnisstand, keine zusätzlichen Einstellungen vornehmen
> bzw. vorhandene überschreiben.
>
Das würde sich ja dann mit meinen Erfahrungen decken. Ich müsste also auf Multiinstance mit postmulti wechseln, statt einen weiteren smtpd in der master.cf zu definieren?

> > Wie kann ich denn erzwingen, dass der smtpd an 127.0.0.1:26 alles versucht
> > an den smtpd an 127.0.0.1:25 zu geben oder alternativ zu bouncen?
>
> ginge, dann hättest Du ja im Endeffekt nur dieses Ziel erreicht, richtig?:
>
> > bekommt das Limit zu spüren und erstellt dann
> > aber ein NDA an den ursprünglichen Absender
>
> Wäre das wirklich der einzige Sinn und Zweck des ganzen Unterfangens?
> Oder verstehe ich das falsch?
>
Ich kann nicht so recht erkennen, was Du glaubst verstanden zu haben. ;-(

Ich möchte auf Mails, die beim Provider liegen und die ich mit fetchmail abhole, mit "zu groß" antworten.
Das beherrscht fetchmail nicht. Ich dachte fetchmail könnte ja einem unlimitierten Mailserver die Mails zur Weiterverarbeitung in die Hand drücken, welcher dann an einen limitierten Mailserver übergibt und im Falle von "zu groß" eben bounced.

> > Nun kommt es hin und wieder vor, dass eine dieser mit fetchmail
> abzuholenden
> > Mails größer ist, als das gewollte message_size_limit des Postfix.
>
> Ist dieses message_size_limit von Dir generell so gewollt oder soll für den
> Empfangsweg via fetchmail ggf. eine Ausnahme gemacht werden?
>
Der Mailserver im LAN hat ein gewolltes message_size_limit. Er bekommt u.a. Mails direkt, weil er MX ist - da funktioniert alles wie gewollt.
Von einer anderen Domain liegen Postfächer bei einem Provider mit einem anderen/keinen message_size_limit. Die Mails will ich reinholen, aber nur die weiterverarbeiten, welche in mein internes Limit passen. Zum Rest möchte ich dem Absender gern sagen "verschicke Deine Nutzlast bitte anders".

Den Provider kann ich nicht zu meinem Wunschlimit zwingen. Fetchmail kann auf Größe nicht mit einer SMTP-Antwort an den Absender reagieren.


> Wenn keine Ausnahme: Was passiert dann eigentlich mit den zu großen
> Mails?
> Die sind ja irgendwo schon mal eingeliefert worden, und der ursprüngliche
> Absender denkt, dass der Empfänger die Mail schon längst in seiner Inbox
> hat.
>
Ja, das ist der Punkt, an dem mein Setup hinkt.
Der Absender beauftragt seine Infrastruktur mir ein Mail zu senden. Mein Provider nimmt an. Für den Absender alles ok.
Ich komme aber aller 5 Minuten hin und gucke nach, ob was da ist. Kleines nehme ich mit nach Hause, auf Großes möchte ich gern reagieren.

In meinem geplanten Setup - da ich auf meinen Provider keinen Einfluss in der Sache habe - bekommt der Absender also nicht beim initialen Senden die rote Karte, sondern ggf. erst 5 Minuten später. Das würde ich als Krücke akzeptieren, denn jetzt liegt die Mail beim Provider, fetchmail überträgt die aller 5 Minuten in mein LAN nur um festzustellen, dass die zu groß ist. Der Absender merkt nichts, und ich habe plötzlich eine langsame Anbindung. Nutze ich --limit in fetchmail, kann ich meine Verbindung schonen, aber Absender und Empfänger wissen noch immer nichts vom Verbleib der großen Mail.

> Wenn jedoch dafür eine Ausnahme erlaubt sein soll: Hattest Du schon mal
> überlegt, die Mails von fetchmail (an Postfix vorbei) direkt an Dovecot zu
> übergeben? Nur so als Gedanke, habe ich selber noch nicht genutzt.
>
Ich habe mit fetchmail einst schon durch procmail(?) direkt in eine mbox oder ein maildir abgelegt. Warum soll das nicht auch mit dovecot gehen? Das ist ja aber nicht was ich will. Ich will das große Mail nicht. Ich will den Absender informieren. Ich will Mails durch meinen postfix leiern, weil da u.a. auch das Archiv dranhängt.


Mit freundlichen Grüßen / Kind regards
     Ronny Seffner

Reply | Threaded
Open this post in threaded view
|

Re: zweite Instanz mit eigenem Transport

Markus Winkler
Hallo Ronny,

On 15.05.20 17:44, Ronny Seffner wrote:
>> ginge, dann hättest Du ja im Endeffekt nur dieses Ziel erreicht, richtig?:
>>
>>> bekommt das Limit zu spüren und erstellt dann
>>> aber ein NDA an den ursprünglichen Absender
>>
>> Wäre das wirklich der einzige Sinn und Zweck des ganzen Unterfangens?
>> Oder verstehe ich das falsch?
>>
> Ich kann nicht so recht erkennen, was Du glaubst verstanden zu haben. ;-(

Ich habe Deine Aussage zitiert und zu verdeutlichen versucht, dass ich das
als Quintessenz Deines geschilderten Problems verstanden habe. ;-) Aber
egal - ich denke schon, dass ich das richtig interpretiert habe und, wie Du
ja hier auch noch mal schreibst:

> Ich möchte auf Mails, die beim Provider liegen und die ich mit fetchmail abhole, mit "zu groß" antworten.

letztlich das Senden einer Benachrichtigung an den Absender der zu großen
Mail als Ziel des Konstrukts übrig bleibt.

>> Ist dieses message_size_limit von Dir generell so gewollt oder soll für den
>> Empfangsweg via fetchmail ggf. eine Ausnahme gemacht werden?
>>
> Der Mailserver im LAN hat ein gewolltes message_size_limit. Er bekommt u.a. Mails direkt, weil er MX ist - da funktioniert alles wie gewollt.
> Von einer anderen Domain liegen Postfächer bei einem Provider mit einem anderen/keinen message_size_limit. Die Mails will ich reinholen, aber nur die weiterverarbeiten, welche in mein internes Limit passen. Zum Rest möchte ich dem Absender gern sagen "verschicke Deine Nutzlast bitte anders".

OK. Also ist das Limit für _alle_ Deine Fälle gesetzt und keine Ausnahme
erlaubt. Klare Verhältnisse. ;-)

> In meinem geplanten Setup

OK, danke, dass Du's noch mal detailliert beschrieben hast, wie Du das
Problem lösen willst. Nur der Vollständigkeit halber: Ich habe zu Sinn und
Zweck dieses Konstrukts eine eher gegenteilige Meinung und würde mir selber
so etwas, wenn ich ehrlich sein darf, nicht antun. Aber meine Einschätzung
tut nichts zur Sache.

>> Wenn jedoch dafür eine Ausnahme erlaubt sein soll: Hattest Du schon mal
>> überlegt, die Mails von fetchmail (an Postfix vorbei) direkt an Dovecot zu
>> übergeben? Nur so als Gedanke, habe ich selber noch nicht genutzt.
>>
> Ich habe mit fetchmail einst schon durch procmail(?) direkt in eine mbox oder ein maildir abgelegt. Warum soll das nicht auch mit dovecot gehen?

Klar, das geht auch mit Dovecot, das war keine Frage - ich wollte diese
Möglichkeit a) nur erwähnen (falls Du Ausnahmen für message_size_limit bei
fetchmail akzeptiert hättest) und b) unterstreichen, dass _ich selbst_
diese konkrete Kombination noch nicht im Einsatz hatte (falls Du
Detailfragen gehabt hättest). ;-)

> Das ist ja aber nicht was ich will. Ich will das große Mail nicht. Ich will den Absender informieren. Ich will Mails durch meinen postfix leiern, weil da u.a. auch das Archiv dranhängt.

Nach deinen Ausführungen von oben ist das klar. Bitte nicht falsch
verstehen, aber IMHO kämpfst Du mit dem Kurieren von Symptomen, wenn ich
das so salopp formulieren darf. Allerdings noch mal betont: Das ist
lediglich meine unmaßgebliche Sicht auf die Situation, die Du geschildert
hast. Ich kann Dir nur leider nicht wirklich bei der Umsetzung Deines
Ansatzes helfen, was ich nämlich tatsächlich gern getan hätte.

Wobei, eine Idee hätte ich noch: Könntest Du Dir nicht einen etwas
flexibleren Provider als den suchen, der bisher diese zu großen Mails
annimmt? Einen, bei dem man z. B. ein gewünschtes Limit konfigurieren kann.
Oder alternativ einen vServer oder irgendwas in dieser preislichen
Kategrier schießen und selbst machen? Du weißt ja offenbar, wie man
Postfix/Dovecot betreibt - warum nicht auch dort selbst machen? Oder gibt
es da Zwänge, bei genau diesem Provider auch den MX betreiben zu müssen.
Nur noch so als Idee ...


Viel Erfolg bei der Suche nach einer Lösung und viele Grüße
Markus
Reply | Threaded
Open this post in threaded view
|

Re: AW: zweite Instanz mit eigenem Transport

Christian Boltz
In reply to this post by Ronny Seffner
Hallo Ronny, hallo zusammen,

Am Freitag, 15. Mai 2020, 16:03:48 CEST schrieb Ronny Seffner:
> > fetchmail kennt die beiden Optionen:
> > --limit
> > --limitflush
>
> Richtig. Dann holt er nicht ab, die Mail bleibt im "ersten"
> Briefkasten. Der Absender glaubt an Zustellung und der Empfänger weiß
> von nix. Darum will ich bouncen/ein NDA und DAS kann fetchmail wohl
> nicht.

Mal eine alternative Idee, bevor Du Dir an der Postfix-Konfiguration die
Finger brichst ;-)

POP3 ist ein relativ einfaches Protokoll. Du könntest also mit
vertretbarem Aufwand ein kleines Programm schreiben, das die von
fetchmail "übriggelassenen" Mails checkt (Header reichen eigentlich) und
dann vom Mailserver löscht.

# telnet localhost pop3
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
+OK Dovecot ready. <2faa.7.5ebfd283.4WAVxsedCLiNVNyssGqTWQ==@tux>
user [hidden email]
+OK
pass topsecret
+OK Logged in.
list
+OK 1 messages:
1 699
.
top 1 50
+OK
[erste 50 Zeilen der Mail incl. Header]
.
dele 1
+OK Marked to be deleted.
quit
+OK Logging out, messages deleted.
Connection closed by foreign host.


Das Ergebnis bei "list" ist   $mailnummer $bytes - Du müsstest also die
zweite Spalte auf übergroße Mails prüfen. Bei denen machst Du dann
erstmal "top 1 50" liefert die ersten 50 Zeilen von Mail 1 - da darfst
du dann den Absender (und evtl. das Subject?) rausparsen und einen
Bounce schicken. Danach kannst Du die Mail mit "dele $mailnummer"
löschen und Dich per "quit" abmelden.

Mit https://docs.python.org/3/library/poplib.html dürfte sowas recht
schnell umzusetzen sein ;-)  (Disclaimer: Ich habe nur die Doku
überflogen, aber dieses Modul nie selbst benutzt.)


Gruß

Christian Boltz
--
>Habt ihr noch einen Vorschlag, wie ich das System beschleunigen könnte?
Aus dem Fenster werfen.
Beschleunigung mit 9,82 m/s²
[> Jan Voehringer und Holger Krull in suse-linux]



Reply | Threaded
Open this post in threaded view
|

AW: zweite Instanz mit eigenem Transport

Ronny Seffner
In reply to this post by Markus Winkler
Hallo Markus,

> verstehen, aber IMHO kämpfst Du mit dem Kurieren von Symptomen, wenn
>
full ack. Aber nicht immer kann EIN Admin die Welt erziehen.


Mit freundlichen Grüßen / Kind regards
     Ronny Seffner