On Wed, Mar 2, 2022 at 3:30 PM Antoine Beaupré wrote:
> Do you plan to pass a significant security audit over the procmail code
> base and fuzz the binary?
>
A binary fuzz is being planned, but if anyone has a ready setup which I can
run, it would be much appreciated.
A security audit I did, tw
On Wed, Mar 2, 2022 at 11:28 AM Santiago Vila wrote:
> Note: It's almost always better not to include a debian/* directory at all.
>
Noted.
Incidentally, all historical release tags are now back in the repository
for as long as the repository goes back.
--
Stephen.
7;s fine. We
> are a free software clearing house, not a dump.
>
> >> That Debian bug report is still open, and concerns a NULL pointer
> >> dereference.
> >
> > I've just make an upload to fix such bug.
>
> I'm sorry, but the fact that it took over
--
Stephen R. van den Berg
Or would it require me to adopt the package in order to get it resurrected?
I use it in all of our systems, and it is starting to get awkward: it still
works, if preinstalled, but I now have to get it from oldstable if it
has not been installed yet.
--
Stephen.
On Fri, 8 Jun 2007 10:05:55 +0200 Matus UHLAR - fantomas
wrote:
> I disagree: ssmtp is very simple mail _submission_ program, which
shouldn't
> take care of delivery in any way. That should be left up to the
mailserver
> specified in config file. The MX records are used for final delivering of
On Tue, 24 Nov 2009 10:49:46 +0100 Michelle Konzack
wrote:
> You complan about the 2048 Bytes sounds realy weird, because base64
> encoded attachment should not have (-> please read the RFC's) more then
> 72 Bytes per line.
>
> If you modify the source code you schould know, that some MTA's can
On Fri, 11 Dec 2009 13:49:58 +0100 Klaus Ethgen wrote:
> The (I think, not so uncommon) usecase is to have a laptop with no
> persistent internet connection. For local Mails I want to have a local
> only mail server. So I need something to flush real mails out when I
> have a internet connection.
On Tue, 29 Aug 2017 17:59:20 +0200 "Stephen R. van den Berg"
wrote:
> I'm going to write a script right now and send it in as a patch. As
> soon as I do, can you
> make sure it ends up in Debian stable?
Well, whipped up a state-of-the-art sysvinit /etc/init.d/bgpd sc
On Fri, 23 Dec 2016 12:52:41 +0800 Scott Leggett wrote:
> On 2016-12-22.11:18, Rui Ribeiro wrote:
> > It is sad people discontinuing functionalities that server a
community and
> > have been working for so many years.
> >
> > I will starting doing my own debs, and will migrate in short time to
Without checking the sources, but merely from memory, I recall that the
problem at heart is/was that procmail maintains (has to maintain) a
"taintedness" of the DEFAULT variable. Meaning that if procmail notices
that DEFAULT has not been touched, that it assumes that it could still
point to th
Guenther did the LMTP support. I vaguely recall discussing this same
issue with him once before. I'd guess that it mostly was/is the fact
that for a new release *with* LMTP support, you'd need to do some more
checks again, and he ran out of time/steam before those could be performed.
After f
In that case I'd say that we should not fix this.
The rule is: if things are undocumented and you are therefore allowed to
guess, and you always guess right, then there is no need to document
it. Please close this ticket.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
On Wed, Oct 16, 2013 at 11:52 AM, Santiago Vila wrote:
> I just wanted to comment on your reply: IMHO, the idea that sysadmins
> should build procmail and perform compile time tests may make sense in
> a *general* way, but IMHO it does not fit very well with Debian spirit.
>
I understand that.
I'll see what I can do to make procmail ignore CR characters immediately
followed by NL in rcfiles (only). This should not break any scripts.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Procmail should be able to do this, but perhaps /dev/stderr doesn't
allow an O_APPEND?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Considering the wording in the RFCs, I have to admit that it is not
according to spec, and since folding apparently happens more frequently
these days, the difference gets noted.
The code is not shared between procmail and formail, the methodology
*is*, however (for consistency's sake).
The re
The original reason the error reporting is not more verbose, is because
of the fact that it created one more system dependency on being able to
get at readable error messages from errno.
The days that procmail needed to compile cleanly on arkane systems are
long gone, and even if so, it's easy
I.e. what happens in your case when the trailing \0 is missing?
Checking the code, it seems like it should accomodate (the state machine
of the parser for that file works for the EOF case). And trying a
testcase it appears to work just fine. Anyone can reproduce the problem?
--
To UNSUBSCRI
The UMASK environment variable is not overwritten at startup to minimise
the trampling on existing values. This is by design.
Maybe it deserves mentioning in the manpage, if not already. The
presented solution by Philip is the official way to use it.
--
To UNSUBSCRIBE, email to debian-bugs
Wouldn't that be stating the obvious?
I mean, yes, we could mention it, then again in order to keep manpages
as short as possible, stating the obvious should be avoided. This is a
sliding scale, I know.
So can you tell me what went wrong or cost you extra time as a result of
this not being m
Seems like this is an unintended side effect. Due to backward
compatibility it is unwise to change the semantics now though.
Your suggested doc fixes seem sound.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@
If there is a < at the start of a regexp, it needs to be escaped. If you
want \< at the beginning of a regexp, you need to double escape the \ at
the beginning.
This is due to the fact that a < character at the beginning of the
regexp has special meaning.
Any suggestions as to how/where to bet
This (locking problem) is not a bug in procmail, as it happens, locking
over NFS is tricky to get right, and it is the responsibility of the
system administrator to get it right using the correct statd/lockd
settings/configuration when mounting the filesystems.
Procmail tries to accomodate for
Putting it lower would mean letting go of the standard order. Then
again, maybe the "standard" from back then is not what it is now.
Suggestions?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
The reason LOGABSTRACT is not set, is because procmail tries not to
contaminate the existing environment more than necessary.
If it is unclear from the existing docs that setting it to yes will
revert to the old behaviour, then that should be clarified.
--
To UNSUBSCRIBE, email to debian-bugs-
One might argue that this could be explained better in the manpage though.
The regexp engine inside procmail is tuned for performance, it therefore
does not do fancy things like finding the longest match. Using the
regexp " *\/.+" is therefore unpredictable, since it can match in many
ways. Wh
What procmail does (the extra >From upfront) is a reaction to a badly
configured mail system.
I have to admit that I'm not quite sure anymore why I picked that way to
communicate this fact.
The intention definitely was not to destroy information, just add. Maybe
I followed someone else's lead ba
The way I viewed it, was that the actual content of the 'From ' line
starts *after* the space. RFC prescribes that mail field content starts
directly after the colon, so by introducing an extra space there in case
of renaming a "From " line, would contaminate the content.
It could be argued t
The reason the spaces are there, is to make sure that nroff properly
breaks if the line gets wider than the screenwidth. I full well realise
that this doesn't help when copy-pasting, and also that if the manpage
is not viewed using nroff, but some kind of webviewer, they should be
taken out.
30 matches
Mail list logo
