milter after queue

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

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?
Reply | Threaded
Open this post in threaded view
|

Re: milter after queue

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: milter after queue

Christos Chatzaras


> On 29 Dec 2018, at 02:56, Wietse Venema <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: milter after queue

Christos Chatzaras
In reply to this post by Wietse Venema


> On 29 Dec 2018, at 02:56, Wietse Venema <[hidden email]> 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).
Reply | Threaded
Open this post in threaded view
|

Re: milter after queue

NBNabble
In reply to this post by Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: milter after queue

Matus UHLAR - fantomas
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, [hidden email] ; 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.
Reply | Threaded
Open this post in threaded view
|

Re: milter after queue

martijn.list
In reply to this post by NBNabble
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