Re: Apple mail fails with Submission
On 18 December 2018 at 02:30 Adi Pircalabu via dovecot < dovecot@dovecot.org> wrote: On 2018-12-18 07:33, Ruud Voorjans wrote: Dear all, I'm running dovecot # 2.3.2.1 - Pigeonhole version 0.5.2 () - OS: Linux 4.18.0-12-generic x86_64 Ubuntu 18.10 with Submission. It works great except with apple mail (Iphone). I get an error with the MTA (postfix): ""postfix/submission/smtpd[32552]: warning: non-SMTP command from mail.example.org [1][xx.xx.xx.xx]: Content-Transfer-Encoding: 7bit"" with other mail-client(s) (Outlook (Desktop and Iphone app)) i have no problem and it proxy-sends the e-mail beautiful out to the recipient. Hardly anything to do with Dovecot. When it comes to email clients Apple Mail has been and is still one of the worst flops (no offence intended, just my opinion based on personal experience). If you can reliably reproduce it, try and log the raw SMTP conversation between Postfix and the client by enabling per IP debugging in Postfix: postconf -e "debug_peer_level = 20" postconf -e "debug_peer_list = xx.xx.xx.xx" postfix reload where xx.xx.xx.xx is the unlucky client IP address. Possibly some crappy SMTP PIPELINING implementation at the Apple end, who knows. -- Adi Pircalabu It's not unconceivable that there are bugs in submission either. Can you provide doveconf -n and submission rawlogs? See https://wiki.dovecot.org/Submission for settings. --- Aki Tuomi
Re: Apple mail fails with Submission
On 2018-12-18 07:33, Ruud Voorjans wrote: Dear all, I'm running dovecot # 2.3.2.1 - Pigeonhole version 0.5.2 () - OS: Linux 4.18.0-12-generic x86_64 Ubuntu 18.10 with Submission. It works great except with apple mail (Iphone). I get an error with the MTA (postfix): ""postfix/submission/smtpd[32552]: warning: non-SMTP command from mail.example.org [1][xx.xx.xx.xx]: Content-Transfer-Encoding: 7bit"" with other mail-client(s) (Outlook (Desktop and Iphone app)) i have no problem and it proxy-sends the e-mail beautiful out to the recipient. Hardly anything to do with Dovecot. When it comes to email clients Apple Mail has been and is still one of the worst flops (no offence intended, just my opinion based on personal experience). If you can reliably reproduce it, try and log the raw SMTP conversation between Postfix and the client by enabling per IP debugging in Postfix: postconf -e "debug_peer_level = 20" postconf -e "debug_peer_list = xx.xx.xx.xx" postfix reload where xx.xx.xx.xx is the unlucky client IP address. Possibly some crappy SMTP PIPELINING implementation at the Apple end, who knows. -- Adi Pircalabu
Possible attack?
I found an error in my log today...
Dec 17 12:03:30 bubba dovecot:
imap(us...@amfes.com)<23017>: Error: fts_solr:
received invalid uid '0'
Dec 17 12:04:44 bubba dovecot:
imap(us...@amfes.com)<25004>: Fatal: master:
service(imap): child 25004 killed with signal 11 (core dumps disabled -
https://dovecot.org/bugreport.html#coredumps)
I've now enabled core dumps (I think) and restarted - if it comes back
hopefully I can get a backtrace. But reading that fts_solr message, and
some other comments, leads me to wonder - could this be caused by
someone/thing trying to authenticate as root?
On that theory - I tried doing so via telnet - and received:
Dec 17 15:06:02 bubba dovecot: auth: Error:
plain(ultradeitytypeper...@amfes.com,127.0.0.1,<4kQr0z99UMZ/AAAB>): user
not found from any userdbs
Dec 17 15:06:02 bubba dovecot: imap: Error: Authenticated user not found
from userdb, auth lookup id=3522297857 (auth connected 1 msecs ago,
handshake 0 msecs ago, request took 1 msecs, client-pid=29572 client-id=1)
I have root's email aliased to a valid user's email. I'm not sure how
I'm able to authenticate as root - there isn't a root user defined in my
LDAP database and that should be the only auth backend enabled for
Dovecot. Or do I need to explicitly block local users from /etc/passwd
on the server? The only auth databases shown in doveconf -n:
userdb {
driver = prefetch
}
userdb {
args = /usr/local/etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
passdb {
args = /usr/local/etc/dovecot/master-users
driver = passwd-file
master = yes
}
passdb {
args = /usr/local/etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
and "master-users" doesn't list root either.
--
Daniel
Re: ECDSA client question
On Sun, 16 Dec 2018, Michael A. Peters wrote: We know there are unexplained constants in the NIST curves including P-256 - what if NSA was partially responsible for this bug (back room deal to avoid anti-trust prosecution, similar deal with IBM was made in the 70s I believe also involving cryptography) so that Android apps that use ECDSA (beyond just the mail client, e.g. chat apps) would use P-256 for compatibility and are maybe vulnerable to MITM for the key exchange. I want Ed25519 now. Bernstein fan? Definitely off-topic, but the gist of his critique of P-256 is that any possible deliberate sabotage of curve parameters is a distraction from the real problem: complexity makes implementation fumbles easy with distrastous consequences. https://cr.yp.to/newelliptic/nistecc-20160106.pdf Joseph Tam
Apple mail fails with Submission
Dear all, I'm running dovecot # 2.3.2.1 - Pigeonhole version 0.5.2 () - OS: Linux 4.18.0-12-generic x86_64 Ubuntu 18.10 with Submission. It works great except with apple mail (Iphone). I get an error with the MTA (postfix): ""postfix/submission/smtpd[32552]: warning: non-SMTP command from mail.example.org[xx.xx.xx.xx]: Content-Transfer-Encoding: 7bit"" with other mail-client(s) (Outlook (Desktop and Iphone app)) i have no problem and it proxy-sends the e-mail beautiful out to the recipient. I think it is some kind of bug or maybe it just isn't supported (yet), cause as you said it is still "pretty basic". Best Regards
Re: Overrideing pop delete?
On 12/15/18 8:09 AM, @lbutlr wrote:
> I have a question about the namespace section.
>
>> You create only a single namespace.
> [...]
> First all, that shows two namespace sections.
When it says "You create only a single namespace", it means you would
create a single extra namespace for the lazy expunge plugin (instead of
creating *three* new namespaces just for the plugin, as in the later
example on that page).
This extra single lazy expunge namespace would be in addition to any
normal namespaces you already have.
> Am I just adding the new namespace for lazy_expunge inside that?
No. Do not touch your existing namespaces at all. You add a new one for
lazy expunge.
> And, finally, is there any way to limit this to only POP3 delete instead of
> all IMAP?
Haven't tried that, but perhaps you could experiment with adding it to
mail_plugins in only the "protocol pop3" section, like:
protocol pop3 {
mail_plugins = $mail_plugins lazy_expunge
}
--
Robert L Mathews, Tiger Technologies, http://www.tigertech.net/
Re: Bug in IDLE implementation for virtual mailbox
On Monday 17 December 2018 10:50:16 Timo Sirainen wrote: > On 17 Dec 2018, at 10.44, Pali Rohár wrote: > > > > On Sunday 16 December 2018 21:55:23 Timo Sirainen wrote: > >> On 16 Dec 2018, at 21.26, Pali Rohár wrote: > >>> > >>> Hello! > >>> > >>> I found bug in Dovecot's IDLE implementation when virtual mailbox is in > >>> use. IDLE does not notify about new emails when email appears in newly > >>> created mailbox and IDLE was issued in virtual folder which matches "*" > >>> wildcard and that mailbox was created after opening virtual mailbox. > >> > >> It actually has nothing to do with IDLE specifically. It's just that the > >> virtual storage code doesn't try to look for new folders after the virtual > >> mailbox is opened. > >> > >>> To get notifications, it is needed to re-open that "All" mailbox again. > >> > >> Right. I don't think this is going to be fixed anytime soon. Quite a lot > >> of effort and it can be worked around. > > > > How to workaround it? Imap clients uses either IDLE or STATUS or LIST > > (with STATUS) commands for checking if there is a new messages. > > > > But none of these commands reports existence of new message until that > > virtual folder is re-opened. > > I mean, workaround is for the user to just reopen the folder. I think it's > not very common for this situation to happen and cause problems? My setup is that I have sieve filters to put emails from mailing lists, bugzilla/github/gitlab/... and other projects into separate own mailbox, based on email headers which these services provides. So once I get email from new bugzilla, github or gitlab project, then sieve automatically creates a new mailbox for it. And this happen every time when I e.g. add a new comment to bugzilla project into which I have not commented yet. I'm having permanently opened mutt email client in tmux/screen on "All" virtual folder to see all new emails. And basically above bug cause problems in this scenario as I would not see new emails. I can re-open "All" mailbox, but first I need to know that new email was received. And for this I'm using mutt IDLing in All virtual folder. So it is like chicken and egg problem. -- Pali Rohár pali.ro...@gmail.com
Re: Bug in IDLE implementation for virtual mailbox
On 17 Dec 2018, at 10.44, Pali Rohár wrote: > > On Sunday 16 December 2018 21:55:23 Timo Sirainen wrote: >> On 16 Dec 2018, at 21.26, Pali Rohár wrote: >>> >>> Hello! >>> >>> I found bug in Dovecot's IDLE implementation when virtual mailbox is in >>> use. IDLE does not notify about new emails when email appears in newly >>> created mailbox and IDLE was issued in virtual folder which matches "*" >>> wildcard and that mailbox was created after opening virtual mailbox. >> >> It actually has nothing to do with IDLE specifically. It's just that the >> virtual storage code doesn't try to look for new folders after the virtual >> mailbox is opened. >> >>> To get notifications, it is needed to re-open that "All" mailbox again. >> >> Right. I don't think this is going to be fixed anytime soon. Quite a lot of >> effort and it can be worked around. > > How to workaround it? Imap clients uses either IDLE or STATUS or LIST > (with STATUS) commands for checking if there is a new messages. > > But none of these commands reports existence of new message until that > virtual folder is re-opened. I mean, workaround is for the user to just reopen the folder. I think it's not very common for this situation to happen and cause problems?
Re: Bug in IDLE implementation for virtual mailbox
On Sunday 16 December 2018 21:55:23 Timo Sirainen wrote: > On 16 Dec 2018, at 21.26, Pali Rohár wrote: > > > > Hello! > > > > I found bug in Dovecot's IDLE implementation when virtual mailbox is in > > use. IDLE does not notify about new emails when email appears in newly > > created mailbox and IDLE was issued in virtual folder which matches "*" > > wildcard and that mailbox was created after opening virtual mailbox. > > It actually has nothing to do with IDLE specifically. It's just that the > virtual storage code doesn't try to look for new folders after the virtual > mailbox is opened. > > > To get notifications, it is needed to re-open that "All" mailbox again. > > Right. I don't think this is going to be fixed anytime soon. Quite a lot of > effort and it can be worked around. How to workaround it? Imap clients uses either IDLE or STATUS or LIST (with STATUS) commands for checking if there is a new messages. But none of these commands reports existence of new message until that virtual folder is re-opened. -- Pali Rohár pali.ro...@gmail.com
