I think not fixing this in the package as a regular fix (it's a patch
after all) is ill-advised,
but for those who find this bug unfixed in their installation:
The workaround is to install asciidoc through pip install --user
asciidoc instead, or possibly with pipx.
Example in line #6 of my test
Package: asciidoc-base
Version: 10.2.0-1
Severity: important
Dear Maintainer,
as a maintainer of the fetchmail upstream package,
I want to build documentation with asciidoc.
As part of fetchmail's build with meson on the legacy_6x branch of
fetchmail, asciidoc is being run, but cannot find
Francesco,
none of the options in that nroff table "user descriptions and options"
mentions arguments to any options, with the exception of sslfingerprint
that gets it wrong - its intention (as inherited from Eric Raymond)
seems to just list the long and their short equivalents, but the
https://gitlab.com/fetchmail/fetchmail/-/issues/56
Control: tags -1 +upstream +fixed-upstream +confirmed
Control: fixed -1 1.12.0
Please note that I have very recently released leafnode 1.12.0 which now
uses PCRE2 instead of PCRE1.
Also note that there is no longer a .bz2 package, only .xz and .gz.
Does this warrant "grave"?
This looks like trying to configure fetchmailconf before fetchmail is
configured, and before fetchmail saw configuration. However why is
fetchmail being "restart"ed? It could not have been running before...
Am 02.01.22 um 17:11 schrieb Karsten:
Basically you can install the self-signed certificate (if you or a
trusted party signed it, and you have transmitted it over a secure
channel, for instance, via SFTP or SCP) into the trust store (assuming
it suits both the TLS server and the signing CA roles
Am 02.01.22 um 14:03 schrieb Karsten:
Am 02.01.22 um 12:15 schrieb Matthias Andree:
I am the owner of the domain so nobody is hijacked!
Are you the owner of "mydomain.de" or of the unnamed domain you intended
not to show to the public?
Do you want to help with this new certifi
Am 02.01.22 um 14:24 schrieb Karsten:
Am 02.01.22 um 12:28 schrieb Matthias Andree:
But it would be helpful for others what must be done to create and install this new
"client side certificate" that
appears about 2018?
I think the certificate issue was there right from the
Am 02.01.22 um 11:54 schrieb Karsten:
Am 01.01.22 um 17:53 schrieb László Böszörményi (GCS):
On Sat, Jan 1, 2022 at 2:30 PM Karsten wrote:
But it would be helpful for others what must be done to create and install this new
"client side certificate" that
appears about 2018?
I think the
Am 01.01.22 um 14:26 schrieb Karsten:
Hello Matthias,
Am 01.01.22 um 14:10 schrieb Matthias Andree:
Notice something?
i notice everything. :-)
You hijack somebody else's domain for "anonymization" purposes and
expect someone to help you, and you did not respond to hints the s
Happy new year Karsten.
Am 01.01.22 um 13:53 schrieb Karsten:
Hello Matthias,
Am 31.12.21 um 20:05 schrieb Matthias Andree:
What must be done to get it working again?
This question has not been answered.
[...]
The security relevant logdata is of course anonymized or altered.
Notice
Am 31.12.21 um 16:32 schrieb Karsten:
Package: fetchmail
Version: 6.4.16-4+deb11u1
Severity: important
I upgraded the server from Debian 9 to 11 and afterwards it seems not possible
to get fetchmail to work.
I tried every possible option of ssl and sslproto, but fetchmail can't fetch
the
Am 24.11.21 um 18:56 schrieb László Böszörményi (GCS):
It would be best if upstream integrates it to the source code. Even
if 6.4.25 is just around the corner.
After some discussion behind the scenes, added to contrib/systemd/ as of
6.4.25.rc2, without installation support.
It should be easy
Just a word of warning, this isn't your pick three git commits with
trivial fixes - the backport will require proper testing, too, and it
will require some of the 42 patches since fetchmail 6.4.21 that are NOT
marked SECURITY - for instance, 74771392 and 616e8c70, and translation
updates as they
On Wed, 18 Aug 2021 19:20:01 +0200 Matthias Andree
wrote:
> The attached patch should fix the crash. envelope is special in that it
> can take the value STRING_DISABLED == (char *)-1 for "no envelope", and
> the optmerge() function did not take this into account and tried to
&
The attached patch should fix the crash. envelope is special in that it
can take the value STRING_DISABLED == (char *)-1 for "no envelope", and
the optmerge() function did not take this into account and tried to
strdup(-1).
This will likely become part of a future 6.4.22 and 6.5.0 release.
diff
Am 22.03.19 um 12:55 schrieb Graeme Vetterlein:
> Package: fetchmail
> Version: 6.3.26-3
> Severity: minor
> Tags: patch
>
> Dear Maintainer,
>
>
> I've just hit an "issue" WRT fetchmail, which I now relaise I hit about 10
> years ago and didn't report
> (shame on me) the "fix" is a simple text
Am 30.03.21 um 09:04 schrieb dk8kk:
> Package: fetchmailconf
> Version: 6.4.0~beta4-3+deb10u1
> Severity: grave
> Tags: a11y
> Justification: renders package unusable
>
> Dear Maintainer,
>
> apt-get update/apt-get upgrade suggests these package for upgrade:
> - fetchmail (6.4.0~beta4-3+deb10u1)
>
Control: tags -1 +fixed-upstream
Integrated upstream into the legacy_6x branch for a future 6.5 release.
https://gitlab.com/fetchmail/fetchmail/-/commit/1b374b5f85147e1714b2499184002b1dc86b8258
+ László
Am 22.01.21 um 21:46 schrieb Erich Wälde:
> Hello,
>
> I found the problem:
>
> The fetchmail config said "tls1" instead of "tls1+", and
> apparently the email hoster enforces tls1.2 now.
> Which is good.
>
> So this bug may be closed.
> Sorry for the noise.
>
> Erich
>
Erich,
Glad
Hi Leszek,
Unfortunately, this has two issues:
1. part of it is in Polish, a language I cannot understand,
2. apparently the debug-run masks the bug. Please
2a. try creating a logfile,
2b. then configure fetchmail to log to the logfile (and not to syslog)
2c. run fetchmail, restart, whatever
Control: tags -1 + patch
With a patch available from Git, I am tagging this accordingly.
Control: tags -1 moreinfo
Is this still relevant?
Control: tags -1 + moreinfo
fetchmail 6.4.13 contains some additional PID handling fixes, but it's
unclear whether those fixes address the issue described here. The logs
provided are insufficient. Please provide logs with full debug trace.
Please provide logs, such as the debug run from the rcscript
Control: tags -1 + moreinfo
Is this still an issue with any of the 6.4 versions, including betas?
I believe that all 6.4.X should be fine.
README.Debian mentions:
/etc/init.d/fetchmail debug-run
what does this get you?
https://sourceforge.net/p/bogofilter/bugs/116/#52a0
i. e. this was fixed 91 commits before bogofilter-1.2.5.rc1. I don't
know if the commit (Git cd33fc00802a75fe7b3b8a967bf879f7bc33c320) works
standalone or only in context, and I'm not researching this because for
me as upstream maintainer, this
trio is only used when the system libraries are insufficient, which
should not be the case with GNU libc.
If a recent Debian build of bogofilter were to include libtrio in the
build, please report that upstream via Gitlab (preferred) or mailing
list with full logs so we can fix that.
trio is
tags 524758 -moreinfo
tags 524758 +confirmed +upstream +fixed-upstream
thanks
I think upstream Git commit 8eaeb85c should fix this.
To appear in the next release after 1.2.5 (which has already been released).
If it does not, please recompile bogofilter with debug log,
provide your test message,
Tags: +confirmed -moreinfo
Found: 1.2.4+dfsg1-13
Found: 1.2.4+dfsg1-9
One simple way to reproduce this appears to be running this without
pre-existing wordlist.db:
echo $'\ngood' | bogofilter -n
echo $'\ngood' | bogofilter -Rv
I am adding a related "make check" test upstream as
Am 05.12.19 um 09:07 schrieb Petter Reinholdtsen:
>
> Anyway, I was just curious what the answer to the question "why" would
> be. Now I know. Thank you for the clarifying answer. :)
>
The answer is actually a bit more complex, with aspects of "problem
already solved externally", "not mandated
Am 04.12.19 um 10:14 schrieb Petter Reinholdtsen:
> [Matthias Andree 2014-05-20]
> While it sure is optional according to RFC5322, it is considered best
> practice to include in in emails. What is the reason the fetchmail
> developers do not want to include Message-ID into these
Control: tags -1 upstream fixed-upstream confirmed
Control: severity -1 grave
Christian, thanks for the report. It is a known issue that happens with
fortifying compilers.
Please use either the former rc3, rc4 or the upcoming 6.4.1. László
(gcs@) is aware of it.
Am 28.09.19 um 00:59 schrieb Alex Andreotti:
> Attention, I was using it with a relative path and it worked, the
> behavior change is that it stopped working, I believe with one of the
> two updates below:
fetchmail behaved inconsistently between daemon and non-detaching modes
in the upstream
Control: tags -1 confirmed upstream
Alex, thanks for your report, you've found a very long-standing
inconsistency in fetchmail's behaviour.
The workaround is to give an *absolute* path for FETCHMAILHOME in daemon
mode. This will be fixed in 6.4.0.
If FETCHMAILHOME is specified as relative path, then it can become
the victim of a chdir("/") that happens in daemon mode, so that
switching to daemon mode will change behaviour of FETCHMAILHOME.
Reported by Alex Andreotti, Debian Bug #941129.
---
NEWS | 3 +++
env.c | 15 ++-
2
On Sun, 07 Jul 2019 15:10:57 -0400 karl wrote:
> Package: libssl1.1.1c-1
> Version: libssl1.1
> Severity: important
>
>
> Began losing email and or attachments 5/19 with a fetchmailrc that had
worked for years.
>
>
> (fetchmail -v)
>
> fetchmail: Loaded OpenSSL library 0x1010103f newer than
Tags: fixed-upstream
This is fixed in the legacy_6x branch on Gitlab,
https://gitlab.com/fetchmail/fetchmail/commit/87626c2707cc0d82e49e160ab3c85430ff33534f
Note the fix requires C99 support because it uses the "long long" type, else
the bug would remain unfixed on 32-bit systems.
On Fri, 21 Jun 2019 11:44:28 +0200 Matthias Andree
wrote:
> On Sat, 27 Oct 2018 20:16:17 +0200 Nicolas Boulenguez
> wrote:
> > Package: fetchmail
> > Followup-For: Bug #872754
> >
> > Hello.
> > I have tried 6.4.0~beta4-1 in experimental.
> > This re
It would seem that this fix should also help FreeBSD architectures where
sizeof(time_t) == 8 everywhere except i386, but 32-bit RISC
architectures such as ARM usually have sizeof(long) == sizeof(void *) == 4.
Basically the bug fixed by tytso@'s patch hits when sizeof(long) <
sizeof(time_t)
On Sat, 27 Oct 2018 20:16:17 +0200 Nicolas Boulenguez
wrote:
> Package: fetchmail
> Followup-For: Bug #872754
>
> Hello.
> I have tried 6.4.0~beta4-1 in experimental.
> This resulted in:
>
> reading message for *:1 among * flushed
> (maybe unrelated) show_signal_msg: 1 callbacks suppressed
>
Control: tags -1 confirmed upstream fixed-upstream -moreinfo -unreproducible
This got fixed in upstream Git as of commit
8c57ec38ae327fcd648569acc915f47f0eb2547d - please cherry-pick this.
https://gitlab.com/fetchmail/fetchmail/commit/8c57ec38ae327fcd648569acc915f47f0eb2547d
Generally, a POP3 DELE becomes effective only with the following QUIT that
completes the session, so the server is compliant.
I shall have a look at the stack and valgrind traces later to see if I can find
the cause.
Please check and report back if this is fixed in 6.4.0~beta4-1
(experimental).
Given the long expected release time until 7.0.0, and that we do not need to
change the interface, I have decided to merge the P-tree .fetchids acceleration
code back into 6.4.0. Laszlo has uploaded the beta4 release to experimental
for your, well, experimentation. Feedback solicited.
Am 15.11.2015 um 06:00 schrieb peter green:
> Tags 804604 +patch
> thanks
>
>> socket.o: In function `SSLOpen':
>> /fetchmail-6.3.26/socket.c:917: undefined reference to
>> `SSLv3_client_method'
>> collect2: error: ld returned 1 exit status
>> Makefile:699: recipe for target 'fetchmail' failed
>>
Actually, O(n * m), where m is the - limited - length of the UID
strings, and in practice, few comparisons are claimed to be necessary on
the average case, on many servers, UID are either very short or share
common prefixes.
It feels a lot faster at any rate with some 10,000 messages in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am 13.09.2015 um 02:38 schrieb Mark Triggs:
> Dear Maintainer,
>
> Recently I've noticed that running 'fetchmail' to awake my
> background fetchmail daemon is quite slow. It takes around 5
> seconds to return, where previously it was pretty much
tags 781803 confirmed upstream fixed-upstream l10n
thanks
Am 03.04.2015 um 16:40 schrieb Nico Golde:
Thanks for the report! Being a native speaker myself, I don't care either way
to be honest, but I can see how beendet sounds a little more professional.
Matthias, do you mind changing this?
When pulling patches, please also grab e6340bf from Git on top of
a2ae6f8 (i. e. apply both, a2... first then e6...).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Am 16.01.2015 um 01:24 schrieb Debian Bug Tracking System:
Processing control commands:
tags -1 + experimental
Bug #775255 [fetchmail] fetchmail: Fails to start when libssl has SSLv3
disabled
Added tag(s) experimental.
IMO this is an error from the shell and the dynamic run-time linker,
Am 09.11.2014 um 17:02 schrieb Kurt Roeckx:
Package: fetchmail
Tags: patch
Hi,
The attached patch improves fethcmail SSL/TLS support. It seems
to have some misunderstandings of openssl / SSL / TLS.
Dear Kurt,
thank you very much for spending time on this matter.
What you are writing
Am 28.02.2014 19:26, schrieb Petter Reinholdtsen:
Package: fetchmail
Version: 6.3.21-4
Hi. When fetchmail is unable to log into the IMAP server to fetch
emails, it inject an email into the mail spool to report this problem.
But the injected email lack message-id, causing the notmuch mail
Am 16.04.2014 07:43, schrieb Gonzalo Pérez de Olaguer Córdoba:
AFAIK, the header field name should remain in english (Subject,
not Asunto) no matter which language is used for the subject body.
Right, thank you for the bug report. I have fixed this in Git -- but it
is unclear if I will ever
libdb4.6 is being phased out according to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510270#35, perhaps
it's time to close this bug on grounds that this was a libdb4.6 bug, not
a bogofilter bug and the requested information hasn't been received in
more than three years.
--
To UNSUBSCRIBE,
software can resolve the names in the very same
instant (a fake poll entry with ssh for its plugin might do that).
Best regards
Matthias Andree
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Nico,
the issue is that fetchmail is currently unable to fetch from read-only
mailboxes and aborts. This will not be fixed for 6.X, but in the long
term (7.X), I plan to track seen/unseen IMAP mail on the client side
(like we already do with POP3 + UIDL), and then this will work.
The only open
I am planning to change this in the next major (7.X) fetchmail release.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
The issue is that the user expects fetchmail to get along with setting
\Deleted, but in fact it additionally sets \Seen. Achieving this requires
changes that are unsuitable for the 6.X series of fetchmail releases, and
requires SEARCH by flags, which not all servers implement. Cloning bug to
Package: fetchmail
Version: 6.3.18-2
Severity: grave
Tags: upstream confirmed fixed-upstream
Control: found 6.3.9~rc2-4+lenny2
Control: found 6.3.21-4
Control: found 6.3.22-2
The bug report included below was filed against Ubuntu, it is an
upstream bug that also affects Debian.
It was originally
XREF Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=955814
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
This is expected behaviour.
--user (or -u) is not a selector, but only overrides the default (which
is the user name of the user running fetchmail).
Effectively, the -u option overrides all username stanzas.
I am demoting this to wishlist because it matches documentation:
*We would need an
To answer the remaining questions:
1. the POP3 server needs to byte-stuff (prepend another dot to lines
starting with a dot)
2. the POP3 clients needs to undo the byte-stuffing (fetchmail's part)
3. an SMTP client needs to byte-stuff (also fetchmail's part)
HTH.
signature.asc
Description:
I cannot reproduce this from a POP3 interface of Exchange 2003, or for a
Dovecot IMAP interface.
Please adhere to standard bug reporting policies at
http://www.fetchmail.info/fetchmail-FAQ.html#G3 (mask passwords where
necessary).
This is likely due to misconfiguration or faults with the
Note that some protocols (ETRN, ODMR) require to send non-delivery
notifications, because we cannot just leave messages on server with them.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Thanks for mentioning this.
This will not be fixed in a 6.X version for compatibility reasons.
(I might fix the manual page for 6.3.25 though.)
I am not tagging wontfix because I do intend to fix this for the
future 7.0.X series.
We'd also need to add support for multiple fingerprints (for
accumulates only then.
Can either of the reporters see and report back if the attached patch
improves the situation for you?
From 7ffec45913adc02a5c5f6a2cfe95a41d42ae535c Mon Sep 17 00:00:00 2001
From: Matthias Andree matthias.and...@gmx.de
Date: Thu, 13 Dec 2012 23:44:37 +0100
Subject: [PATCH] Plug
Erik,
without either debugging info of a leak detector, or bare necessities to
reproduce the situation per the FAQ
http://www.fetchmail.info/fetchmail-FAQ.html#G3, there is no chance
this can ever be fixed.
(This does not rule out a lucky coincidence, but such a coincidence
might happen in a few
Am 18.09.2012 13:49, schrieb Erik Thiele:
Am 18.09.2012 12:53, schrieb Nico Golde:
Hi,
* Erik Thiele erik.thi...@thiele-hydraulik.de [2012-09-18 09:48]:
[...]
how can I further supply information on this issue? It is a production
machine, but maybe I can somehow help find the cause of the
Alexander,
thank you for the patch. I have committed it to fetchmail's Git
repository, but it is not yet part of a formal release.
http://gitorious.org/fetchmail/fetchmail/commit/f77204551bb10e8c05acd8a607ee9db4ad48cf47
NEWS file entry:
Trevor,
thank you for taking the time to report a problem.
However, it is not helpful if bug reporters get carried away to guess
what might have happened, and draw false conclusions.
Facts:
- fetchmail treats response codes the same no matter if they
are returned in reponse to MAIL FROM, or
Does Hurd support pathconf(/var/spool/news, _PC_PATH_MAX)?
Which value does it return?
Does Hurd return a value no smaller than _POSIX_PATH_MAX (256)?
I might consider replacing PATH_MAX by a pathconf all to the spool
directory for systems where PATH_MAX is missing, because that is covered
by
This should be 'normal' severity, changing it.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: fetchmail
Version: 6.3.18-2
Severity: important
Tags: upstream, fixed-upstream, patch
Hi Nico,
just to remind you there's a patch at
http://gitorious.org/fetchmail/fetchmail/commit/138baebcae334c2c222c0d0299148fe1aef0315c
that fixes a bug where fetchmail's IMAP client, in versions 6.3.5
Am 22.08.2011 00:22, schrieb Anders Kaseorg:
On 08/12/2011 03:19 AM, Matthias Andree wrote:
The IMAP standard (RFC-3501) has clear requirements with respect to how
long servers need to tolerate connections left idle by clients,
As much as the proxy’s behavior sucks, the proxy is under
Am 12.08.2011 00:13, schrieb Anders Kaseorg:
Package: fetchmail
Version: 6.3.18-2
I’m running fetchmail through a proxy server that drops any connections
left idle for more than a little over 2 minutes. In order to be able to
use IMAP IDLE, I need to reduce this hardcoded timeout value
Am 02.07.2011 19:52, schrieb Samuel Thibault:
Package: fetchmail
Version: 6.3.19-1
Severity: normal
Hello,
I run two fetchmail daemones, one using idle mode for one imap account,
and one in batch mode for all the other ones. I'm thus using the -f and
--pidfile option so that they don't
commit c22a3afca46c83ee6d53a6ee58deb122f309c460
Author: Matthias Andree matthias.and...@gmx.de
Date: Mon Apr 11 14:08:32 2011 +0200
Remove support for SSLv2 (fixes Debian Bug #622054).
SSLv2 has been deprecated since 1996, and is insecure.
Remove --sslproto SSL2 support
/wiki/TestDisk (note I haven't tried it yet).
--
Matthias Andree
(FreeBSD ports committer)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
/fetchmail/+bug/684228
But it is not to be expected that Ubuntu will see to those in the near future.
--
Matthias Andree
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
call, however, _does_ yield the proper path (dist-packages), then
check the build scripts where it gets overridden, if there are siteconfig files
for autoconf, or config.caches where a wrong pythondir might get picked up.
HTH
--
Matthias Andree
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ
This is mostly solved - 6.3.10 and newer have a softbounce option
that can be set to keep mail on the POP3 server even if the SMTP
server refuses such mail.
However, I still think that such illegit mail should not be allowed
to clog up the inbox and should be deleted.
--
To UNSUBSCRIBE, email
This bug seems non-trivial to fix: in imap_idle(), we wait for untagged
responses, and may be deep in SSL_peek -- and that restarts the
underlying blocking read() from the socket, so we never break out of the
SSL_peek() with SIGUSR1.
This won't be fixed in fetchmail 6.3.X.
--
To UNSUBSCRIBE,
be packaged for experimental, or for
unstable with a marker to NOT migrate to testing until we have evidence
that the bug is really fixed in -pre2.
--
Matthias Andree
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
accept further authentication attempts in the same session.
Looks like we need to remove the auto feature, or to add a repoll
feature for IMAP, too, and trigger it on authentication failures. This
also needs a proper framework to lock methods that fail.
--
Matthias Andree
--
To UNSUBSCRIBE
Nico, Héctor,
this was repeated again and again on the fetchmail list, and it is a
massive regression from Debian 4.0 - and we can solve it with a patch.
I have asked Patrick Rynhart and Alan Murrell to test [1] (it may need a
few more of the previous commits, too, see [2], and disregard
diagnosing the cause.
Best
--
Matthias Andree
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Am 21.05.2010 15:39, schrieb Nico Golde:
Hi,
* Jan Braun janbr...@gmx.net [2010-05-21 13:38]:
Fetchmail's init script should probably depend on exim4 and $named,
rather than just $network. At least here, with dependency-based boot
enabled, the first run always fails because DNS (a local
tags 580796 confirmed upstream
thanks
Roland Stigge schrieb:
Package: fetchmail
Version: 6.3.17-1
Severity: normal
Hi,
I just upgraded fetchmail from 6.3.15-1 to 6.3.17-1 and suddenly, it says:
$ fetchmail
fetchmail: Warning: the connection is insecure, continuing anyways. (Better
tag 580796 patch
thanks
Find attached a patch to hopefully solve that problem.
Works for me, but please test.
diff --git a/socket.c b/socket.c
index a3adfd8..2ebdfc6 100644
--- a/socket.c
+++ b/socket.c
@@ -1009,8 +1009,8 @@ int SSLOpen(int sock, char *mycert, char *mykey, const char *myproto,
retitle 578956 fetchmail drops messages with non-header lines in header section
severity 578956 wishlist
tags 578956 fixed-upstream
found 578956 6.3.6-1etch1
found 578956 6.3.6-1etch2
found 578956 6.3.6-1etch3
found 578956 6.3.9~rc2
found 578956 6.3.9~rc2-4+lenny1
found 578956 6.3.9~rc2-4+lenny2
I'd also concur that default to commit -a would be a most undesireable
astonishment for me. Please don't go that way. Thanks.
(Not that I believe it stands a chance of upstream integration, but to avoid
downstream distro-specific shipwrecks.)
--
Matthias Andree
--
To UNSUBSCRIBE, email
Am 23.04.2010 22:17, schrieb Goswin von Brederlow:
Wincent Colaiuta w...@wincent.com writes:
El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:
You all say the index is such a great thing. So I might use it
eventually. Other people might use it 1 out of 10 times. Yet other
people
that sees to your Exchange server.
I propose to close this bug as it's not a fetchmail bug. (If it can
later be proven to be, you can reopen it.)
--
Matthias Andree
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
.
-- http://rt.openssl.org/Ticket/Display.html?id=2224
- see http://openssl.org/support/rt.html for access credentials.
So perhaps that explains why it has gone unnoticed all the time - if
certificates only used the mandatory algorithms, it simply wasn't needed.
--
Matthias Andree
Confirmed - a regression in 6.3.15 (and -beta3). Sorry. Will be fixed in
6.3.16 shortly.
--
Matthias Andree
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
.
Nothing about OpenSSL_add_all_algorithms().
If the OpenSSL documentation is so incomplete, I may have to switch the
SSL library inside stable versions to avoid such issues.
Thank you.
--
Matthias Andree
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
.
NTLM or password should work for you.
I believe this was somewhat obvious enough, but let me know your
suggestions for improvement.
HTH
--
Matthias Andree
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
1 - 100 of 273 matches
Mail list logo
