Re: milter after queue
On 08-05-2020 14:11, NBNabble wrote: > I have a question to your hint using a null SMTP based listener. > > I am Using Ciphermail as an encryption gateway. > Pre-Queue mails are send to an external milter for Spam/Virus Checks. > After that, post-queue, the encryption gateway is a content_filter. > > I am looking for a solution to resend the mails to the milter again, after > the first content filter. > So in case there is malware in a decrypted mail, I also get that. > > Do you have any idea, how I could recheck the mails again with the milter? > Post queue? After the Ciphermail gateway (post-queue), the Ciphermail back-end sends the email back to Postfix on port 10026 for further delivery (reinjection). The default config for the reinjection port (10026) disables milters (see master.cf): receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters Try to see whether it works when you remove "no_milters" Kind regards, Martijn Brinkers
Re: milter after queue
On 08.05.20 05:11, NBNabble wrote: Hi Wietse, I am not wietse but I hope it won't distract you. I have a question to your hint using a null SMTP based listener. I am Using Ciphermail as an encryption gateway. Pre-Queue mails are send to an external milter for Spam/Virus Checks. After that, post-queue, the encryption gateway is a content_filter. I am looking for a solution to resend the mails to the milter again, after the first content filter. So in case there is malware in a decrypted mail, I also get that. Do you have any idea, how I could recheck the mails again with the milter? Post queue? milter is SMTP-level option. However, if you need to check something again, your decryption gateway can return mail on a IP:port where milter will run too. Note that you must take care of what happend if the second milter will reject the mail - what will the decryption gateway do. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I intend to live forever - so far so good.
Re: milter after queue
Hi Wietse, I have a question to your hint using a null SMTP based listener. I am Using Ciphermail as an encryption gateway. Pre-Queue mails are send to an external milter for Spam/Virus Checks. After that, post-queue, the encryption gateway is a content_filter. I am looking for a solution to resend the mails to the milter again, after the first content filter. So in case there is malware in a decrypted mail, I also get that. Do you have any idea, how I could recheck the mails again with the milter? Post queue? -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: milter after queue
> On 29 Dec 2018, at 02:56, Wietse Venema wrote: > > Maybe you can figure out why rspamd is slow. Are you sending huge > messages, or is rspamd slow because of DNS lookups? > > Maybe you can use /usr/sbin/sendmail for local submissions? This > requires configuring non_smtpd_milters in main.cf. > > Otherwise, you can run milters post-queue, with a null SMTP-based > content filter (Postfix SMTP client sending directly into Postfix > SMTP server). > > /etc/postfix/master.cf ># The default before-queue SMTP port, configured ># to send mail through a null SMTP filter. >smtp inet .. .. .. .. .. .. smtpd >-o content-filter=smtp:127.0.0.1:10025 > ># New post-queue SMTP port. Set 'no content filter' ># to avoid mailer loops (belts and suspenders). >127.0.0.1:10025 inet .. .. .. .. .. .. smtpd > -o smtpd_milters=inet:127.0.0.1:12345 > -o content_filter= > ># Optional, to use rspamd for /usr/sbin/sendmail submissions. >pickup unix .. .. .. .. .. .. pickup > -o content-filter=smtp:127.0.0.1:10025 > > Untested, but it should be very close. > > Wietse Maybe the issue was related to this message: "got IO timeout with server fuzzy2.rspamd.com(212.24.145.107:11335), after 1 retransmits" At the moment I block in my firewall UDP port 11335. In the relays the port is open. I will try tomorrow to see if it's related to this timeout (I think it timeouts in 4 seconds).
Re: milter after queue
> On 29 Dec 2018, at 02:56, Wietse Venema wrote: > > Maybe you can figure out why rspamd is slow. Are you sending huge > messages, or is rspamd slow because of DNS lookups? > > Maybe you can use /usr/sbin/sendmail for local submissions? This > requires configuring non_smtpd_milters in main.cf. > > Otherwise, you can run milters post-queue, with a null SMTP-based > content filter (Postfix SMTP client sending directly into Postfix > SMTP server). > > /etc/postfix/master.cf ># The default before-queue SMTP port, configured ># to send mail through a null SMTP filter. >smtp inet .. .. .. .. .. .. smtpd >-o content-filter=smtp:127.0.0.1:10025 > ># New post-queue SMTP port. Set 'no content filter' ># to avoid mailer loops (belts and suspenders). >127.0.0.1:10025 inet .. .. .. .. .. .. smtpd > -o smtpd_milters=inet:127.0.0.1:12345 > -o content_filter= > ># Optional, to use rspamd for /usr/sbin/sendmail submissions. >pickup unix .. .. .. .. .. .. pickup > -o content-filter=smtp:127.0.0.1:10025 > > Untested, but it should be very close. > > Wietse Thank you for your reply. No it's not because of DNS lookups. RBLs are disabled in Rspamd as I use RBLs in Postfix. Finally I solve the issue by sending the outgoing e-mails to postfix relays and then the relays use the Rspamd milter for outgoing e-mails. Also I configure as you described Rspamd milter only for incoming e-mails at the main servers.
Re: milter after queue
Christos Chatzaras: > I install rspamd in a server and I use postfix milter from another > server to scan outgoing e-mails. > > I have a php script that sends mails. Before the rspamd milter the > e-mails I sent using the php script where added in the postfix > queue and the php script finish execution in few seconds. Then the > e-mails in queue sent within few minutes. > > Now it takes a long time because it sends e-mails without using > postfix queue and the php script timeouts. > > Is it possible to scan outgoing messages using rspamd after adding > the e-mails to queue? Maybe you can figure out why rspamd is slow. Are you sending huge messages, or is rspamd slow because of DNS lookups? Maybe you can use /usr/sbin/sendmail for local submissions? This requires configuring non_smtpd_milters in main.cf. Otherwise, you can run milters post-queue, with a null SMTP-based content filter (Postfix SMTP client sending directly into Postfix SMTP server). /etc/postfix/master.cf # The default before-queue SMTP port, configured # to send mail through a null SMTP filter. smtp inet .. .. .. .. .. .. smtpd -o content-filter=smtp:127.0.0.1:10025 # New post-queue SMTP port. Set 'no content filter' # to avoid mailer loops (belts and suspenders). 127.0.0.1:10025 inet .. .. .. .. .. .. smtpd -o smtpd_milters=inet:127.0.0.1:12345 -o content_filter= # Optional, to use rspamd for /usr/sbin/sendmail submissions. pickup unix .. .. .. .. .. .. pickup -o content-filter=smtp:127.0.0.1:10025 Untested, but it should be very close. Wietse
