similar to: Dovecot - T-Bird - RETR command failed

Greetings everyone. My dovecot mail server doesn't execute *train-spam.sh* script I set, when moving an e-mail from "Inbox" to "Junk" within Outlook. However, it does it fine when using an online webmail client a.k.a. Roundcube Webmail. Here are few lines from my maillog file showing the situation. Any idea would be much appreciated. Log output of the mentioned process:

Hi Aki! Thank you for your reply. Sure, here are the related lines within my conf files and sieve scripts: https://hastepaste.com/view/Erk8Ra Thank you so much, Regards. Aki Tuomi <aki.tuomi at open-xchange.com>, 5 Mar 2020 Per, 11:31 tarihinde ?unu yazd?: > > > On 5.3.2020 9.00, ?zg?r Kazancci wrote: > > Greetings everyone. > > > > My dovecot mail server

I have successfully installed IceCast with SSL support : https://relay2.dgnet.be/ Stream is working fine with this URL : https://relay2.dgnet.be:443/different.ogg Nevertheless the listen URL still points to http://relay2.dgnet.be:443/different.ogg ( without https then ) So the links provided/generated by IceCast are wrong . What did I miss ? Is it possible to force the listenurl value in the

I understand there are two types of relays in icecast2. The master relay which relays everything from a source and a point relay which relays a specific mount point from a source. I have a server which has 3 streams. I want to relay 2 of them. How can I do this? Can I define two relays and two mountpoints within the xml config file? Do i do this in the same relay tag: <relay>

Hi Justin, >Are you talking about the listen URL in the Icecast status page? I think it is currently not able show the link as httpS. Maybe one of the Icecast experts can confirm that. Yes I was talking about this value. The workaround was to put my own m3u file ( with the correct link ) in the icecast web folder > Is this truly an OGG audio file? Why does the server response give a

No, this is a relay of a Shoutcast server. Everything is configured in https on IceCast ( https://relay2.dgnet.be/ ) , except this value listenurl ( in Admin / Mountpoint) which in cannot change apparently. So the .m3u file is created with an http:// link ( instead of https:// ) But the stream is available and working in https://relay2.dgnet.be:443/different.ogg Danny From: Icecast

Hm, look what I got hold of today.. Works if sendmail is mode 4111 or similar: #! /bin/sh # # # Hi ! # This is exploit for sendmail smtpd bug # (ver. 8.7-8.8.2 for FreeBSD, Linux and may be other platforms). # This shell script does a root shell in /tmp directory. # If you have any problems with it, drop me a letter. #

My ISP uses Dovecot and I have had an ongoing problem for a while using several email clients. Sometimes the response to a retr request is mal-formed. The expected response "+OK nnn octets" is not returned. The response looks like it started somewhere in the message headers. Sometimes a retry can clear the problem but I usually need to delete the first message via a putty session.

Hello, I'm getting the following error while Mozilla Mail is downloading >4000 emails: The RETR command did not succeed. Error retrieving message. Mail server xxx responded: Message is deleted. So what's the error? Can't I retrieve a message, that has been marked as deleted before? If the Mesage-ID wouldn't exist, the error message would be different. I don't know

Hi, Looks like there's a bug while logging RETR bytes. Is this really a bug? What should I check in order make it work? /etc/dovecot.conf pop3_logout_format = top=%t/%T, retr=%r/%R, del=%d/%m, size=%s Sample log: dovecot: Apr 26 18:03:55 Info: pop3(xxxx): Logout. top=0/0, retr=1/ del=1/1, size=3556 dovecot: Apr 26 18:03:46 Info: pop3(xxxx): Logout. top=0/0, retr=4/ del=4/4, size=66191

On 09 Apr 2015, at 06:52, Guillermo M. Narvaja <guillermo.narvaja at fierro.com.ar> wrote: > > Since December 2014, clients using the Python poplib library (getmail in > my case) started to limit the line length of RETR and other command > responses sent from the server to 2048 bytes: > > See https://bugs.python.org/issue16041 (Included at least in > Python-2.7.9) >

On 10 Apr 2015, at 17:51, Guillermo M. Narvaja <guillermo.narvaja at fierro.com.ar> wrote: > > El vie, 10-04-2015 a las 10:21 +0900, Timo Sirainen escribi?: >> On 09 Apr 2015, at 06:52, Guillermo M. Narvaja <guillermo.narvaja at fierro.com.ar> wrote: >>> >>> Since December 2014, clients using the Python poplib library (getmail in >>> my case)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 21 Mar 2017, Bappasaheb Nirmal wrote: > Dovecot log is showing too many POP3 RETR entries which are identical lines. > I also suspect that it is causing high pop traffic eating most of the network > bandwidth. Here are some of the lines out of 11009 in a day. Such pattern is > observed only for few users. dovecot version is

On 5.3.2020 9.00, ?zg?r Kazancci wrote: > Greetings everyone. > > My dovecot mail server doesn't execute *train-spam.sh* script I set, > when moving an e-mail from "Inbox" to "Junk" within Outlook. > > However, it does it fine when using an online webmail client a.k.a. > Roundcube Webmail. > > Here are few lines from my maillog file showing the

Ah. This is because you only match COPY, and outlook is doing APPEND+EXPUNGE instead. Aki On 5.3.2020 10.39, ?zg?r Kazancci wrote: > Hi Aki! > > Thank you for your reply. > > Sure, here are the related lines within my conf files and sieve > scripts: https://hastepaste.com/view/Erk8Ra > > Thank you so much, > Regards. > > Aki Tuomi <aki.tuomi at

Since December 2014, clients using the Python poplib library (getmail in my case) started to limit the line length of RETR and other command responses sent from the server to 2048 bytes: See https://bugs.python.org/issue16041 (Included at least in Python-2.7.9) Dovecot doesn't have line split in the POP3 module, so Python fails to retrieve messages with long lines. RFC 1939 says: "

I have given up on using any spam training with Outlook because Outlook seems rebuild the mails when you touch them. What it broke here: * Received Headers reshuffled and useless * x-mailer set to outlook There are multiple bug reports about this and MS seems to have fixed it once in Outlook 2010 but broke it again sometime later. I would be careful not to spam-report yourself with those mails

Danny, Are you talking about the listen URL in the Icecast status page? I think it is currently not able show the link as httpS. Maybe one of the Icecast experts can confirm that. In case you didn't know, you don't need the port (:443) in the URL. Is this truly an OGG audio file? Why does the server response give a Content-Type of "audio/mpeg"? Justin On 2020-03-20

El vie, 10-04-2015 a las 10:21 +0900, Timo Sirainen escribi?: > On 09 Apr 2015, at 06:52, Guillermo M. Narvaja <guillermo.narvaja at fierro.com.ar> wrote: > > > > Since December 2014, clients using the Python poplib library (getmail in > > my case) started to limit the line length of RETR and other command > > responses sent from the server to 2048 bytes: >

Hello, Dovecot log is showing too many POP3 RETR entries which are identical lines. I also suspect that it is causing high pop traffic eating most of the network bandwidth. Here are some of the lines out of 11009 in a day. Such pattern is observed only for few users. dovecot version is 2.1.17. ============== Mar 20 00:00:07 pi3 dovecot: pop3(user at example.com): Disconnected: Logged out