On Wed, May 04, 2011 at 03:00:04PM -, Matthias Andree wrote:
> The -a naturally cannot fix the bogus permissions of the /var/run
> directory, as logged here:
>
> May 4 16:56:28 hermes postfix/local[813]: 894EE47DFD: to=,
> orig_to=, relay=local, delay=0.06, delays=0.01/0/0/0.05,
> dsn=4.3.0,
The -a naturally cannot fix the bogus permissions of the /var/run
directory, as logged here:
May 4 16:56:28 hermes postfix/local[813]: 894EE47DFD: to=,
orig_to=, relay=local, delay=0.06, delays=0.01/0/0/0.05,
dsn=4.3.0, status=deferred (temporary failure. Command output: ERR:
authdaemon: s_connec
On Wed, May 04, 2011 at 01:42:34PM -, Matthias Andree wrote:
> Please don't patch authlib - it's too silent already, and maildrop's
> "can't connect" is hard enough to find - namely non-existent if run from
> Postfix.
maildrop has two straightforward modes - when you don't specify -a and when
Please don't patch authlib - it's too silent already, and maildrop's
"can't connect" is hard enough to find - namely non-existent if run from
Postfix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1029
On Wed, May 04, 2011 at 12:34:33PM -, Matthias Andree wrote:
> Note that this has been restated several times before, see comment #15.
> See https://bugs.launchpad.net/ubuntu/+source/courier-
> authlib/+bug/777060 for additional details. It might be advisable to
> make maildrop depend on courie
Note that this has been restated several times before, see comment #15.
See https://bugs.launchpad.net/ubuntu/+source/courier-
authlib/+bug/777060 for additional details. It might be advisable to
make maildrop depend on courier-authdaemon.
Josip, note that it is NOT fetchmail BUT getmail that balk
Re https://bugs.launchpad.net/ubuntu/+source/courier-
authlib/+bug/102947/comments/17 the underlying problem is that
/var/run/courier/authdaemon gets created with wrong permissions so that
unprivileged agents cannot access the .../socket in that directory.
Linking a duplicate bug here.
--
You rec
On Mon, Feb 07, 2011 at 12:56:54PM -, foolishchild wrote:
> The fix is easy:
> - sudo aptitude purge maildrop
> - download the maildrop tar.bz2 from
> http://www.courier-mta.org/download.php#maildrop
> - follow the install instructions
> - sudo aptitude install libpcre3-dev
> - ./configur
The fix is easy:
- sudo aptitude purge maildrop
- download the maildrop tar.bz2 from
http://www.courier-mta.org/download.php#maildrop
- follow the install instructions
- sudo aptitude install libpcre3-dev
- ./configure
- ./make
- ./make install-strip
- ./make install-doc
- change .fetch
I had the same problem on my system 10.04
After modifying the permissions on the /var/run/courier/authdaemon
directory the error disappeared
chmod 755 /var/run/courier/authdaemon/
--- the error ---
Oct 27 15:02:24 servername postfix/pipe[10665]: B30227076F:
to=, relay=maildrop, delay=0.17, dela
On Thu, Jul 29, 2010 at 08:57:34PM -, Simon Elsbrock wrote:
> For each mail fetched, maildrop seems to be returning the
> following error:
>
> msg 1/1 (7036 bytes), delivery error (command maildrop 10858 error (67,
> ERR: authdaemon: s_connect() failed: No such file or directory
> Invalid
I can also confirm this bug (Ubuntu 10.04 LTS with maildrop 2.2.0-3.1).
I use getmail4 to fetch mails and try to deliver them using maildrop as
an MDA. For each mail fetched, maildrop seems to be returning the
following error:
msg 1/1 (7036 bytes), delivery error (command maildrop 10858 error
In the third sentence I obviously meant to say - that there was *no*
failure.
--
ERR: authdaemon: s_connect() failed: No such file or directory
https://bugs.launchpad.net/bugs/102947
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ub
Yes. The message goes to stderr and maildrop tries to continue. In case
authdaemon is not essential to message delivery, the message is harmless
and maildrop succeeds. That is why its exit code indicates
(definitively) that there was a failure. However, in cases where
authdaemon *is* essential to m
I'm running 10.04, and this bug (or one very closely related to it) is
still a problem.
I have a user cron that runs a script to retrieve mail like so:
/usr/bin/fetchmail -a -s -m "/usr/bin/maildrop -d %T"
The maildrop binary is permissioned thusly:
-rwxr-sr-x 1 root mail 174168 2010-02-02 00:56
Hi there,
This is just to confirm that this is still happening in 9.04. It's purely
maildrop issue, fetchmail has nothing to do with it. You can test it by calling:
maildrop -d
It will issue the error message. Looks like maildrop was compiled to be a part
of courier. As mentioned above Courier-a
Still an issue on 9.04. I have the same setup, fetchmail + maildrop,
with courier-authlib installed (but authdaemon NOT running). I get my
emails but in fetchmail.log I get:
ERR: authdaemon: s_connect() failed: No such file or directory
after every mail it downloads.
--
ERR: authdaemon: s_conne
Thanks for the information.
** Changed in: maildrop (Ubuntu)
Importance: Undecided => Medium
Assignee: Andrea Corbellini (andrea-bs) => (unassigned)
Status: Incomplete => Confirmed
** Changed in: courier-authlib (Ubuntu)
Importance: Undecided => Medium
Status: Incomplete
Thank you for taking the time to report this bug and helping to make
Ubuntu better. You reported this bug a while ago and there hasn't been
any activity in it recently. We were wondering if this is still an issue
for you. Can you try with the latest Ubuntu release? Thanks in advance.
** Changed in
Still an issue on 8.10.
Installing courier-authdaemon does not fix it.
--
ERR: authdaemon: s_connect() failed: No such file or directory
https://bugs.launchpad.net/bugs/102947
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-b
** Changed in: maildrop (Ubuntu)
Sourcepackagename: fetchmail => maildrop
--
ERR: authdaemon: s_connect() failed: No such file or directory
https://bugs.launchpad.net/bugs/102947
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu
This is not a fetchmail bug, but happens inside maildrop, which tries to
communicate with authdaemon. Please reassign to authdaemon or maildrop.
--
ERR: authdaemon: s_connect() failed: No such file or directory
https://bugs.launchpad.net/bugs/102947
You received this bug notification because you
It seems that I don't have the package 'courier-authdaemon' installed,
which is responsible for creating that socket. After installing
'courier-authdaemon', I no longer receive the error.
--
ERR: authdaemon: s_connect() failed: No such file or directory
https://bugs.launchpad.net/bugs/102947
You
On Ubuntu 7.10 AMD64, I performed:
# strace authtest [EMAIL PROTECTED] "password"
It looks like there is a socket, '/var/run/courier/authdaemon/socket',
it is attempting to access, which is not on the system. Specifically,
'/var/run/courier/ does not exist. I've attached the output from
'strace
Hi, this is the similar message that I've seen. I use fetchmail +
maildrop + mutt + esmtp to retrieve my gmail via POP3
Running fetchmail --verbose gives me:
fetchmail: reading message [EMAIL PROTECTED]:23 of 258 (6274729 octets)
#ERR: authdaemon: s_connect() failed: No such
25 matches
Mail list logo