search for: missing_domain

It seems that Dovecot gets confused when presented with a header like: From: someone at somewhere.org i.e. with leading whitespace and no "friendly name" This shows up as ""@MISSING_DOMAIN in clients, such as Pine, that believe what Dovecot tells them rather than parsing the headers themselves (e.g. Thunderbird). Here's a sample IMAP session: xyz FETCH 728 ENVELOPE * 728 FETCH (ENVELOPE ("Tue, 22 Mar 2005 10:10:50 +0100 (BST)" "Test" ((NIL NIL "&quot...

Hello, we are working in the migration from courier-imap to dovecot 2.2.10-4.el7_0.1.x86_64. Some emails that send a internal application show as sender "MISSING_MAILBOX at missing_domain", i use like email client Horde using dovecot like server. But if i open that email with Horde and courier-imap i can see the correct email sender. I think that the email of the sender is no correct or not accomplish some RFC. Can anyone help me to understand this? Thank you

Any word about this issue? Should I file a bug in an actual bug tracker or something? //Mike On Sat, 15 Aug, 2020 at 13:26, Michael Gratton <mike at vee.net> wrote: > Hi all, > > I'm seeing Dovecot include the string "MISSING_DOMAIN" in fetch > envelope requests when an mailbox's `addr-spec` part does not have a > `domain` part. > > For example: > >> C: a022 uid fetch 40 (envelope rfc822.header) >> S: * 5 FETCH (UID 40 ENVELOPE ("Sat, 15 Aug 2020 12:53:05 +1000" >> &qu...

Hi all, I'm seeing Dovecot include the string "MISSING_DOMAIN" in fetch envelope requests when an mailbox's `addr-spec` part does not have a `domain` part. For example: > C: a022 uid fetch 40 (envelope rfc822.header) > S: * 5 FETCH (UID 40 ENVELOPE ("Sat, 15 Aug 2020 12:53:05 +1000" > "test {{name}}" (("Michae...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 14 Oct 2015, grupo correo wrote: > we are working in the migration from courier-imap to dovecot > 2.2.10-4.el7_0.1.x86_64. > > Some emails that send a internal application show as sender > "MISSING_MAILBOX at missing_domain", i use like email client Horde using > dovecot like server. But if i open that email with Horde and courier-imap i > can see the correct email sender. > > I think that the email of the sender is no correct or not accomplish some > RFC. Can anyone help me to understand this? W...

On 31 Aug 2020, at 06:23, Michael Gratton <mike at vee.net> wrote: > Any word about this issue? Should I file a bug in an actual bug tracker or something? I don't think it's a bug? -- Eliot: We'll figure it out. We always do. Margo: When it's a test to cheat on. Not when we're stuck in some epic fantasy that likes to behead heroes halfway through season

...n configure to send a dummy To: header, which we do. Our To header looks like: To: "AdminCc of rt Ticket #123456":; The message_address_parse function called with the TRUE flag (triggers add_fixed_address) in dovecot changes that to To: AdminCc of rt Ticket #123456: MISSING_MAILBOX at MISSING_DOMAIN ; and then at least alpine does use that invalid address as Cc: address when replying. If the mail is stored in a local folder, i.e. does not get fetched via IMAP then the To: line is displayed as is and a reply does not result in an errorneous Cc: This behaviour is at least inconsistent from...

I've had complaints from users about "MISSING_DOMAIN" in header fields and I've tracked it down to having "." in an unquoted display name. By my reading of RFC2822 (especially section 4.1) A N Other <a.n.other at somewhere.org> "A. N. Other" <a.n.other at somewhere.org> are legal, but A. N. Other <a.n....

...ted. * SEARCH 1 00000009 OK Search completed. * 1 FETCH (UID 1 INTERNALDATE "01-Aug-2005 16:23:17 -0400" RFC822.SIZE 319 FLAGS (\Seen) ENVELOPE ("Mon, 1 Aug 2005 16:23:17 -0400 (Eastern Daylight Time)" "Hidden synchronization message" ((NIL NIL "Bynari" "MISSING_DOMAIN")) ((NIL NIL "Bynari" "MISSING_DOMAIN")) ((NIL NIL "Bynari" "MISSING_DOMAIN")) NIL NIL NIL NIL NIL) BODY[HEADER.FIELDS (DATE X-PRIORITY X-BYNARI-FOLDER-CLASS X-PR-CONTAINER-CLASS X-MESSAGE-FLAG RECEIVED)] {135} Date: Mon, 1 Aug 2005 16:23:17 -0400 (Easte...