DKIMproxy before or after queue ?

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

DKIMproxy before or after queue ?

Frank Bonnet
Hello

I plan to install DKIMproxy and I wonder which would be the more efficient
solution : before or after queue ?

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: DKIMproxy before or after queue ?

mouss-2
Frank Bonnet wrote:
> Hello
>
> I plan to install DKIMproxy and I wonder which would be the more
> efficient
> solution : before or after queue ?


- dkimproxy can do verification or signing. I guess you mean
verification (dkimproxy_in).
- before which queue? I guess you mean at reception time (smtpd port 25)
to be able to reject mail.

If so, then it's really up to you. you won't reject a lot of mail this
way, so there is no statistical justification.

If you are using spamassassin, you can let it do dkim verification.

If it's for signing, signed mail should not be altered, so you should
run dkimproxy_out at the very last moment.


Reply | Threaded
Open this post in threaded view
|

Re: DKIMproxy before or after queue ?

Bob001
In reply to this post by Frank Bonnet
There is a huge debate about it if you are using mailing list..I guess eventually you will.
And if it is mailman, I am also looking for similar steps for after queue.

 
On 6/18/08, Frank Bonnet <[hidden email]> wrote:
Hello

I plan to install DKIMproxy and I wonder which would be the more efficient
solution : before or after queue ?

Thanks

Reply | Threaded
Open this post in threaded view
|

Re: DKIMproxy before or after queue ?

Victor Duchovni
In reply to this post by Frank Bonnet
On Wed, Jun 18, 2008 at 09:24:19AM +0200, Frank Bonnet wrote:

> I plan to install DKIMproxy and I wonder which would be the more efficient
> solution : before or after queue ?

I would do pre-queue verification, because verification involves multiple
DNS lookups, and the latency cost of these is more easily ammortized
over a large population of "smtpd" listeners (that slow down the sender
as necessary) than over a low concurrency post-queue filter.

Signing I would do post-queue, and would strongly consider 7-bit downgrade
before signing (remove 8BITMIME from the EHLO response on the filter
re-injection port).

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: DKIMproxy before or after queue ?

mouss-2
Victor Duchovni wrote:

> On Wed, Jun 18, 2008 at 09:24:19AM +0200, Frank Bonnet wrote:
>
>  
>> I plan to install DKIMproxy and I wonder which would be the more efficient
>> solution : before or after queue ?
>>    
>
> I would do pre-queue verification, because verification involves multiple
> DNS lookups, and the latency cost of these is more easily ammortized
> over a large population of "smtpd" listeners (that slow down the sender
> as necessary) than over a low concurrency post-queue filter.
>
> Signing I would do post-queue, and would strongly consider 7-bit downgrade
> before signing (remove 8BITMIME from the EHLO response on the filter
> re-injection port).
>  

would a pre-queue (in an after the queue part of the chain) help reduce
disk IO?

Reply | Threaded
Open this post in threaded view
|

Re: DKIMproxy before or after queue ?

Victor Duchovni
On Thu, Jun 19, 2008 at 12:40:38AM +0200, mouss wrote:

> would a pre-queue (in an after the queue part of the chain) help reduce
> disk IO?

No, because the DKIM filter does the same disk I/O whether it is a
proxy in front of the re-injection SMTP server, or behind it. The
in-front approach reduces the process count and process to process
copies.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.