<html>
<head>
<style type="text/css">
body,p,td,div,span{
font-size:14px;font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
};
body p{
margin:0px;
}
</style>
</head>
<body><div>Hi,</div><div><br></div><div>fetchmail kennt die beiden Optionen:</div><div>--limit</div><div>--limitflush</div><div>damit kann man vermeiden, dass zu große Mails abgerufen werden und auf dem Server gelöscht werden.</div><div>zum anderen kann man über die Option</div><div>--smtphost</div><div>Mails direkt dem Postfix zustellen, auch auf einem anderen Port</div><div><br></div><div>https://www.fetchmail.info/fetchmail-man.html#10</div><br><div>Gruß</div><div>Stefan</div><div><br></div>--- Original Nachricht ---<br><b>Betreff: </b>zweite Instanz mit eigenem Transport<br><b>Von: </b>"Ronny Seffner" <ronny@seffner.de><br><b>An: </b>postfixbuch-users@listen.jpberlin.de<br><b>Datum: </b>14-05-2020 18:18<br><br><br><br><blockquote style="border:0;border-left: 2px solid #22437f; padding:0px; margin:0px; padding-left:5px; margin-left: 5px; ">Hallo Liste,<br>
<br>
ich dachte mein Problem ist einfach zu Lösen.<br>
Da ist ein funktionierender postfix, der die "lokalen"<br>
Empfängerinformationen via virtual_ aus MySQL zieht. Zusätzlich holt ein<br>
fetchmail noch ein paar fremde Postfächer ab und übergibt sie dem Postfix.<br>
Nun kommt es hin und wieder vor, dass eine dieser mit fetchmail abzuholenden<br>
Mails größer ist, als das gewollte message_size_limit des Postfix. Leider<br>
kann nach meiner Kenntnis fetchmail damit nicht gut umgehen und versucht<br>
diese Mails eben wieder und wieder erfolglos abzuholen.<br>
<br>
Nun war meine Idee, in der master.cf einfach für einen weiteren smtpd zu<br>
sorgen, der ein weniger strenges message_size_limit fährt. An diesen soll<br>
fetchmail liefern. Nun soll diese zweite Instanz aber die Post der ersten<br>
Instanz in die Hand drücken, bekommt das Limit zu spüren und erstellt dann<br>
aber ein NDA an den ursprünglichen Absender (was fetchmail ja leider nicht<br>
beherrscht). Mir ist klar, dass es technologisch sauberer wäre, diese<br>
externen Postfächer würden schon entsprechend limitieren.<br>
<br>
Was nun aber passiert, ist dass diese neue Instanz - egal wie ich es<br>
konfiguriere - irgendwie den transport "dovecot" aus den virtual_*_maps der<br>
main.cf "erbt" und nicht überschrieben bekommt. In der Dokumentation finde<br>
ich auch keinen Hinweis, dass das nicht gehen soll.<br>
<br>
postconf -n<br>
<br>
compatibility_level = 2<br>
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd<br>
$daemon_directory/$process_name $process_id & sleep 5<br>
dovecot_destination_recipient_limit = 1<br>
html_directory = no<br>
inet_protocols = ipv4<br>
local_transport = local<br>
mailbox_size_limit = 0<br>
mydomain = LOCALDOMAIN.TLD<br>
mynetworks = 127.0.0.0/8, 192.168.2.0/24<br>
mynetworks_style = subnet<br>
relay_domains = $mydestination<br>
relayhost = RELAY.DOMAIN2.TLD<br>
sender_canonical_maps = hash:/etc/postfix/sender_canonical<br>
smtp_sasl_auth_enable = yes<br>
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password<br>
smtp_sasl_security_options = noanonymous<br>
smtp_tls_loglevel = 1<br>
smtp_use_tls = yes<br>
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated,<br>
reject_unknown_client_hostname<br>
smtpd_helo_required = yes<br>
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,<br>
reject_unauth_destination, reject_unauth_pipelining,<br>
reject_non_fqdn_recipient<br>
smtpd_relay_restrictions =<br>
smtpd_sasl_auth_enable = yes<br>
smtpd_sasl_local_domain = $mydomain<br>
smtpd_sasl_path = private/auth<br>
smtpd_sasl_type = dovecot<br>
smtpd_sender_login_maps =<br>
mysql:/etc/postfix/mysql-virtual_sender_permissions.cf<br>
smtpd_sender_restrictions = check_recipient_access<br>
hash:/etc/postfix/recipient_access, check_sender_access<br>
hash:/etc/postfix/sender_access, permit_mynetworks,<br>
reject_sender_login_mismatch, permit_sasl_authenticated,<br>
reject_unknown_helo_hostname, reject_unknown_recipient_domain,<br>
reject_unknown_sender_domain,<br>
transport_maps = hash:/etc/postfix/transport<br>
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual_alias_maps.cf<br>
virtual_gid_maps = static:2000<br>
virtual_mailbox_base = /<br>
virtual_mailbox_domains =<br>
mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf<br>
virtual_mailbox_limit = 0<br>
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual_mailbox_maps.cf<br>
virtual_transport = dovecot<br>
virtual_uid_maps = static:2000<br>
<br>
<br>
die oben genutzte transport map<br>
<br>
DOMAIN.TLD :[127.0.0.1]<br>
<br>
<br>
und der entscheidende Teil in der master.cf<br>
<br>
127.0.0.1:26 inet n - y - - smtpd<br>
-o message_size_limit=102400000<br>
-o virtual_transport=<br>
-o virtual_mailbox_maps=<br>
-o virtual_mailbox_domains=<br>
-o virtual_alias_maps=<br>
-o relayhost=[127.0.0.1]<br>
<br>
<br>
Immer wenn ich an 127.0.0.1 ein Mail für DOMAIN.TLD abgebe, geht die nicht<br>
an den 127.0.0.1:25 und hat im Log "relay=dovecot".<br>
Wie kann ich denn erzwingen, dass der smtpd an 127.0.0.1:26 alles versucht<br>
an den smtpd an 127.0.0.1:25 zu geben oder alternativ zu bouncen?<br>
<br>
<br>
Mit freundlichen Grüßen / Kind regards<br>
Ronny Seffner</blockquote></body></html>