Re: transport_maps not taking on
On 8/8/2019 10:41 AM, Kai Schaetzl wrote: I have still one question, though. I fear that forwarding the mail via transport may not consult the milter. At the moment the remote Exchange is still not configured to accept the domain. I'm still waiting for that to take place. In the meantime, though, I would have expected that the course of action is the following: - postfix accepts the mail to this domain - applies the restrictions - once the mail has successfully passed the restrictions - it delivers to the transport-specified destination But in this case I should see a connection to and validation by the milter before postfix tells me that the remote Exchange won't accept it. And it doesn't do that. Or does it first check if it would be able to deliver to the destination before it applies the other restrictions? The rspamd milter is set to get consulted at the end of smtpd_recipient_restrictions = .. .. check_policy_service inet:127.0.0.1:10024, permit and: smtpd_delay_reject = yes Will this check the milter before the message is sent over to the transport-specified nexthop? Thanks for a clarification! Kai That looks like a policy service and not a milter. Regardless, postfix accepts mail, running it through all configured milters, restrictions, and policy services, then puts it in the queue. THEN it consults the transport table to see where to deliver it. (this is somewhat over-simplification, but should answer your question) -- Noel Jones
Re: transport_maps not taking on
I have still one question, though. I fear that forwarding the mail via transport may not consult the milter. At the moment the remote Exchange is still not configured to accept the domain. I'm still waiting for that to take place. In the meantime, though, I would have expected that the course of action is the following: - postfix accepts the mail to this domain - applies the restrictions - once the mail has successfully passed the restrictions - it delivers to the transport-specified destination But in this case I should see a connection to and validation by the milter before postfix tells me that the remote Exchange won't accept it. And it doesn't do that. Or does it first check if it would be able to deliver to the destination before it applies the other restrictions? The rspamd milter is set to get consulted at the end of smtpd_recipient_restrictions = .. .. check_policy_service inet:127.0.0.1:10024, permit and: smtpd_delay_reject = yes Will this check the milter before the message is sent over to the transport-specified nexthop? Thanks for a clarification! Kai
Re: Postfix not using LMTP Transport in map
Maztec wrote on Thu, 8 Aug 2019 01:13:18 -0700 (MST): > However, Mailman3 does not use a socket - > nonetheless I tried. I wrote that because your service specification in master.cf says it does use a Unix socket. I think you have to specify that in the mailman3 service in your master.cf! That's where everything should go if you use a postfix service specification. Then postfix picks everything up from there. I have it that way for a vacation service and the entry in the transport map just sends to "vacation:". Maybe use inet:portnumber instead of unix as the type. (I don't know if you can specify the portnumber this way.) Did you follow a tutorial for delivering to mailman the way you want to do it? (I didn't look for one.) Kai
Re: transport_maps not taking on
I went back to my original config with virtual users and domains, with and without the milter. I left transport and mynetworks as they were. I have no idea why, but it's working now and I get a bounce from the remote server (= it's not yet accepting the mail). No more attempts to deliver locally or put on hold. I hope it remains that way. Thanks for the help! Kai
Re: transport_maps not taking on
Wietse Venema wrote on Wed, 7 Aug 2019 19:33:05 -0400 (EDT): > Once a message enters in the hold queue IT WILL SIT THERE FOREVER > unless something releases it from that queue. Understood. Thanks! I should have known from the past (see below). > > You need to figure out why messages are placed on the hold queue. > One example is when a Milter returns a "quarantine" action. Another > one is Mailscanner. I used to use MailScanner until one or two years ago. Yeah, you actually configure Postfix to put all incoming messages in the hold queue, MailScanner scans it and puts it actively in the delivery queue. rspamd doesn't put them to quarantine. If I requeue the message with -r it is put on hold again very soon. According to man postsuper the requeue does not subject it to the milter again. But I will take it out of the equation for now to be sure. It looks to me like I must have disabled any attempt to deliver to a transport at all. Kai
Re: sasl config confusion postfix 2.10.1
* Fazzina, Angelo : > > Hi, I added this to main.cf > > relayhost = [massmail.uconn.edu]:587 > smtp_fallback_relay = [massmail.uconn.edu]:587 > smtp_sasl_auth_enable = yes > smtp_sasl_password_maps = hash:/etc/postfix/nexus_passwd > smtp_sasl_security_options = This is looking ok. You're talking to [massmail.uconn.edu]:587 using SASL and the password is in /etc/postfix/nexus_passwd > I added this to master.cf > submission inet n - n - - smtpd > -o syslog_name=postfix/submission > -o smtpd_tls_security_level=encrypt > -o smtpd_sasl_auth_enable=yes > -o milter_macro_daemon_name=ORIGINATING I don't think you need this at all. > Aug 7 12:27:28 production0 postfix/cleanup[18993]: 89C1F121242FF: > message-id=<20190807162728.89c1f12124...@production0.nexus.uconn.edu> > Aug 7 12:27:28 production0 postfix/bounce[19011]: 85A08121242FE: sender > non-delivery notification: 89C1F121242FF > Aug 7 12:27:28 production0 postfix/qmgr[18989]: 89C1F121242FF: from=<>, > size=3290, nrcpt=1 (queue active) > Aug 7 12:27:59 production0 postfix/smtp[18995]: 89C1F121242FF: > to=, > relay=massmail.uconn.edu[137.99.26.55]:587, delay=31, delays=0/0/31/0, > dsn=5.7.0, status=bounced (host massmail.uconn.edu[137.99.26.55] said: 530 > 5.7.0 Must issue a STARTTLS command first (in reply to MAIL FROM command)) > Aug 7 12:27:59 production0 postfix/qmgr[18989]: 89C1F121242FF: removed > > > What am I doing wrong ? Your machine is client to massmail.uconn.edu Your machine needs to use STARTTLS before it issues a SMTP AUTH command smtp_tls_security_level = may smtp_tls_loglevel = 1 smtp_tls_note_starttls_offer = yes # you might need to use your own keys/certificates here, these are # mine and my paths smtp_tls_key_file = /etc/ssl/private/mail-cvk-int.charite.de.key smtp_tls_cert_file = /etc/ssl/certs/mail-cvk-int.charite.de.pem-chain smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Postfix not using LMTP Transport in map
Update:The error message my mail client receives is as follows: "lmtp:+51c0564a95aa31a8840305bec77e9023baa46477"@Domain.TLD *User doesn't exist: lmtp:@Domain.TLD* (in reply to RCPT TO command)and "lmtp:[127.0.0.1]:8024"@Domain.TLD (expanded from l...@list.tld): host Domain.TLD[private/dovecot-lmtp] said: 550 5.1.1 "lmtp:[127.0.0.1]:8024"@Domain.TLD User doesn't exist: lmtp:[127.0.0.1]:8...@domain.tld (in reply to RCPT TO command)The first example above came as a result of a suggestion by Kai that my transport map was incorrect. Specifically, he suggested that I could remove the port specification and that mailman3 is operating on a socket. However, Mailman3 does not use a socket - nonetheless I tried. The result was the same.*Despite the directive for Postfix to use the LMTP Transport *(either via lmtp or the mailman3 alias - I have configured for both), *it still uses the dovecot-lmtp and ignores the mailman lmtp.* Furthermore, it places the mailman lmtp into the address TO space, rather than utilizing the mailman3 transport method.I'm at a loss for what is going on here... -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
