Robert Spier wrote:
This gets us into DJB vs not-DJB, which is not somewhere I really want
to go. Personally, I like all my configuration in one place, instead
of having to look in multiple files.
That ship sailed a really long time ago:
1) we are using daemontools as the process management
> I'd also like to pitch my alternate ./run file, which uses DJB's
> envdir to seperate the runtime configuration (which lives in ./env)
> from the application configuration (which lives in ./config like
> before). So the script I use is this:
This gets us into DJB vs not-DJB, which is not somewh
Robert Spier wrote:
Yes, but not with those names. They're somewhat meaningless. Also,
for the first one, do you have a path to perl hardcoded?
How about qpsmtd_debug and qpsmtpd_test? And I don't have to hardcode the path,
because both of them run as a logged in user (and hence don't have
John Peacock wrote:
John Peacock wrote:
2) Always spool the file when body_filename() is called.
And yet, when size_threshold > 0, IO::File was not flushing small
files to disk, so it still didn't work right. I added an explicit
$self->{_body_file}->close();
and now EICAR gets caught
> I also have useful alternate run scripts in my local branch that
> others might find useful:
>
> 1) ./debug - loads qpsmtpd via tcpserver using the Perl debugger under
> the current user and port 2525;
>
> 2) ./test - loads qpsmtpd via forkserver using the current user and
> port 2525.
>
> Sho
John Peacock wrote:
2) Always spool the file when body_filename() is called.
And yet, when size_threshold > 0, IO::File was not flushing small files
to disk, so it still didn't work right. I added an explicit
$self->{_body_file}->close();
and now EICAR gets caught either way.
I al
John Peacock wrote:
After doing a little research, it appears some of the Netsky viruses
are around 2k in size. But my second point is still valid: if you are
using this for a spamtrap, you aren't going to scan for viruses, so it
doesn't matter. If you _are_ scanning for viruses, you want to
> > +1
>
> I suppose that means you expect me to do it? ;-)
Exactly.
> Would it be better to make config() respect =cut instead so we can
> include POD that can be used as is?
That seems like an unnecessary complication of the config format.
-R
Robert Spier wrote:
I also committed a change to default to 0 (and an example config
file). I wonder if we shouldn't document all of the config.example
files using POD protected by #'s and then create an automatic
README.config file out of those stubs.
+1
I suppose that means you expect me t
Robert Spier wrote:
Didn't we also change the default memory_threshold to 0?
Doesn't matter, because the code wasn't working right. I just checked
in some changes to branch/0.31 which should take care of all of the issues:
1) Correctly override the memory_threshold (now renamed to
size_thr
Didn't we also change the default memory_threshold to 0?
-R
Charlie Brady wrote:
1) Are there any actual viruses in the wild <10k in size (with the
assorted mail headers remember) other than the EICAR test?
Even if there aren't today, there may be in the future. I don't think
it's worth taking risk on.
After doing a little research, it appears some o
On Thu, 22 Sep 2005, John Peacock wrote:
Gordon Rowell wrote:
If messages are smaller than 10k, the scanners don't get to see them:
You aren't the first to note this, unfortunately. It appears that the
memory_threshold override is not working correctly (which is really the
appropriate wa
Gordon Rowell wrote:
If messages are smaller than 10k, the scanners don't get to see them:
You aren't the first to note this, unfortunately. It appears that the
memory_threshold override is not working correctly (which is really the
appropriate way to handle this, IMNSHO), though I believe
On Sep 21, 2005, at 10:50 PM, Gordon Rowell wrote:
So, I guess the TODO needs to be done. And if we're not doing this
for 0.31, we should mention (a form of) the workaround in the
release notes.
Seems important enough to get in 0.31. (And it justifies me not
having put it out yet ;-) )
This one took a little digging. I upgraded to 0.31 (from 0.29) in SME
Server 7.0beta4, and we've had bugs raised about ClamAV and SpamAssassin
not working. They are, just not for small mails...
If messages are smaller than 10k, the scanners don't get to see them:
https://sourceforge.net/tracke
16 matches
Mail list logo
