ithout checking the replies qpstmpd sends and that's saved
in STDIN unless it's cleared.
Best regards,
Diego d'Ambra
smime.p7s
Description: S/MIME Cryptographic Signature
as lowered to 30 secs.
This seems to clear enough "hanging children" to get email flowing again.
Note that I've only looked at dumped traffic from a few of these German
connections and they contained nothing but what looked like spam messages.
Best regards,
Diego d'Ambra
single standard exists for "bounce messages".
Best regards,
Diego d'Ambra
Charlie Brady wrote:
Looks like your message wasn't delivered to the list - so I've included
your full reply.
On Fri, 20 Oct 2006, Diego d'Ambra wrote:
You could also try to deny emails where the is empty
(bounce messages).
Of course, if you do that, then your users
)
Some of these may have been solved in other places, but I would be
willing to test and check if they are still needed and patch against
latest revision.
Any interest?
Best regards,
Diego d'Ambra
smime.p7s
Description: S/MIME Cryptographic Signature
stumbled over 1 minor issue.
Daemon fails to start if using argument --interface, due to tainted data
in $d_addr.
Suggested patch attached, note I've little experience with IPv6 and
module Data::Validate::IP doesn't yet support it, so others may want to
add IPv6 validation.
Best rega
o
try delivery.
Any thoughts how to fix this?
Best regards,
Diego d'Ambra
smime.p7s
Description: S/MIME Cryptographic Signature
Diego d'Ambra wrote:
Sending an email using tls plugin with qpsmtpd-prefork (revision 936)
will result in child exiting next time a client connects with:
[...]
Any thoughts how to fix this?
Ugly fix is to "taste" if e.g. STDIN looks open just before child is
going to ret
Hanno Hecker wrote:
On Tue, 19 Aug 2008 13:23:05 +0200
Diego d'Ambra <[EMAIL PROTECTED]> wrote:
Diego d'Ambra wrote:
Sending an email using tls plugin with qpsmtpd-prefork (revision 936)
will result in child exiting next time a client connects with:
Ugly fix is to "taste
Radu Greab wrote:
[...]
Here is a patch, tested on async, forkserver and prefork, that, by my
tests, fixes the problem. Please review it and if there are no
objections I will commit it in the following days:
Works also here, thanks :-)
Best regards,
Diego d'Ambra
smime.p7s
Descripti
o the validation, or did I miss
something?
I'm working on a way to test this, but would love to hear others
opinion, before doing to much work for maybe nothing :-)
Best regards,
Diego d'Ambra
smime.p7s
Description: S/MIME Cryptographic Signature
Hanno Hecker wrote:
Hi Diego,
On Sat, 27 Sep 2008 10:11:15 -0400
Matt Sergeant <[EMAIL PROTECTED]> wrote:
On Sat, 27 Sep 2008 13:56:58 +0200, Diego d'Ambra wrote:
To me it seems that plugin DNSBL is using Net::DNS bgsend/bgread, but
is not checking the id of the reply received.
Matt Sergeant wrote:
On Sat, 27 Sep 2008 13:56:58 +0200, Diego d'Ambra wrote:
To me it seems that plugin DNSBL is using Net::DNS bgsend/bgread, but
is not checking the id of the reply received.
If true this means that an attacker can white- or blacklist any email
Thinking more about
Diego d'Ambra wrote:
[...]
I made a little change to DNSBL to ensure it randomize scr port and I
see a major difference.
Maybe latest version of Net::DNS does this (after Dan's widely report
exploit). My box is an older Sarge solution, so others may not see same
issue.
But
Diego d'Ambra wrote:
To me it seems that plugin DNSBL is using Net::DNS bgsend/bgread, but is
not checking the id of the reply received.
[...]
Attached suggested patch. Large part of it inspired by how Spamassassin
does it.
Changelog:
* Added source port randomisation to DNS qu
the reason.
Latest version of prefork also handles a possible race better, the
parent will detect a lock and reset shared memory.
--
Best regards,
Diego d'Ambra
smime.p7s
Description: S/MIME Cryptographic Signature
Charlie Brady wrote:
On Fri, 29 May 2009, Diego d'Ambra wrote:
[...]
Latest version of prefork also handles a possible race better, the parent
will detect a lock and reset shared memory.
Sorry, I've to correct myself, that's not true. Apparently my previously
suggested
fects?
Parent using more CPU time looking after children, but I guess it's minor.
If not, it might be a good idea to set this upstream.
Why not set --idle-children at start-up to something higher (or just 0
to disable)?
--
Best regards,
Diego d'Ambra
smime.p7s
Description: S/MIM
Robert Spier wrote:
Diego d'Ambra wrote:
Charlie Brady wrote:
On Fri, 29 May 2009, Diego d'Ambra wrote:
[...]
Latest version of prefork also handles a possible race better, the
parent will detect a lock and reset shared memory.
Sorry, I've to correct myself, that's not
Diego d'Ambra wrote:
[...]
But you're right, there is also code in the reaper function - remove the
array of children terminated, hmmm... I think we should delete that.
This can't be deleted - parent is using this to track children, clean-up
and possible reset of shared me
kids around that aren't
needed.
I understand :-)
As for disabling idle-children.. what exactly would the
behavior be with disabled idle children?
Parent would spawn --max-children.
--
Best regards,
Diego d'Ambra
smime.p7s
Description: S/MIME Cryptographic Signature
21 matches
Mail list logo