[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fv4ERwB6KSgzWGT6wwNELZVBMV-KOyynVnSZfj5C9C-c":3},{"data":4,"related":95},{"id":5,"title":6,"slug":7,"excerpt":8,"cover":9,"category":11,"author":14,"track":20,"level":23,"reading_minutes":26,"is_featured":27,"published_at":28,"updated_at":28,"body":29,"toc":30,"tags":66,"faqs":79,"related_services":89,"comments_enabled":93,"meta_title":19,"meta_description":94,"canonical_url":19,"noindex":27,"is_live":93},41,"ایمیل تحویل داده می‌شود ولی Inbox خالی است؛ تله‌ی mail_location","postfix-dovecot-mail-location-empty-inbox","ایمیل در لاگ Postfix «تحویل داده» می‌شود اما کاربر هنگام اتصال IMAP صندوق خالی می‌بیند. علت رایج، اختلاف مسیر تحویل میان Postfix و mail_location در Dovecot است.",{"url":10,"alt":6},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F48b5cdce-7a37-4e0d-af2d-4a25bbafd20f.webp",{"name":12,"slug":13},"ابزارهای Self-Hosted","self-hosted",{"name":15,"slug":16,"role":17,"bio":18,"linkedin_url":19,"avatar_url":19},"تحریریه کلودیکپ","cloudicap-editorial","تیم محتوای کلودیکپ","تیم فنی و محتوای کلودیکپ؛ مهندسانی که هر روز با DevOps، Kubernetes و زیرساخت ابری کار می‌کنند و تجربه‌هایشان را اینجا می‌نویسند.",null,{"value":21,"label":22},"engineers","مهندسان",{"value":24,"label":25},"intermediate","متوسط",7,false,"2026-11-12T06:14:11+00:00","\u003Ch2 id=\"مسئله-ایمیل-تحویل-داده-شد-ولی-صندوق-خالی-است\">مسئله: ایمیل «تحویل داده شد»، ولی صندوق خالی است\u003C\u002Fh2>\n\u003Cp>سناریو را ببینید. کاربر می‌گوید ایمیلی به من نمی‌رسد، یا ایمیل‌هایی که ارسال شده‌اند در Inbox نیستند. سراغ \u003Ccode>\u002Fvar\u002Flog\u002Fmail.log\u003C\u002Fcode> می‌روید و می‌بینید همه‌چیز از نظر Postfix سالم است:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">postfix\u002Flmtp[29341]: 4Xk2...: to=<ali@example.com>, relay=example.com[\u002Fprivate\u002Fdovecot-lmtp], delay=0.12, status=sent (250 2.0.0 <ali@example.com> Saved)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>یا اگر LDA در مسیر باشد:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">postfix\u002Flocal[29344]: 4Xk2...: to=<ali@example.com>, relay=local, delay=0.21, status=sent (delivered to maildir)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>ولی به محض اینکه کاربر با Thunderbird یا Roundcube وصل می‌شود، INBOX خالی است. در \u003Ccode>\u002Fvar\u002Flog\u002Fdovecot.log\u003C\u002Fcode> معمولاً یکی از این خطوط را می‌بینید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">imap(ali@example.com)<...>: Error: chdir(\u002Fhome\u002Fali\u002FMaildir) failed: No such file or directory\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>یا این:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">Error: open(\u002Fvar\u002Fvmail\u002Fexample.com\u002Fali\u002FMaildir\u002Fdovecot-uidlist) failed: Permission denied\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>حتی ممکن است هیچ خطایی هم نبینید؛ Dovecot یک صندوق خالی می‌سازد و همه‌چیز از بیرون سالم به نظر می‌رسد. نکته‌ی کلیدی این است: \u003Cstrong>Postfix پیام را در یک مسیر می‌نشاند و Dovecot مسیر دیگری را نگاه می‌کند\u003C\u002Fstrong>. کاربر نه خطا می‌بیند، نه \u003Ca href=\"\u002Fservices\u002Fmail-server-self-hosted\">ایمیل\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2 id=\"علت-ریشه‌ای-دو-جفت-کلید-که-با-هم-هماهنگ-نیستند\">علت ریشه‌ای: دو جفت کلید که با هم هماهنگ نیستند\u003C\u002Fh2>\n\u003Cp>در یک سرور ایمیل، تحویل پیام و ارائه‌ی IMAP دو لایه‌ی جداست. Postfix مسئول گرفتن پیام است و Dovecot مسئول نمایش آن. اگر این دو درباره‌ی «محل صندوق» توافق نداشته باشند، پیام در یک جا می‌نشیند و کاربر جای دیگری را نگاه می‌کند. سه منبع تفرق را بررسی کنید:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>mbox در برابر Maildir:\u003C\u002Fstrong> Postfix با \u003Ccode>home_mailbox = Maildir\u002F\u003C\u002Fcode> در \u003Ccode>main.cf\u003C\u002Fcode> به \u003Ccode>~\u002FMaildir\u002F\u003C\u002Fcode> می‌نویسد، ولی مقدار پیش‌فرض Dovecot روی بعضی توزیع‌ها \u003Ccode>mbox:~\u002Fmail:INBOX=\u002Fvar\u002Fmail\u002F%u\u003C\u002Fcode> است. دو مسیر کاملاً متفاوت.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>مبنای virtual_mailbox:\u003C\u002Fstrong> در حالت کاربران مجازی، Postfix با \u003Ccode>virtual_mailbox_base\u003C\u002Fcode> به یک مسیر می‌نویسد و Dovecot با \u003Ccode>mail_location\u003C\u002Fcode> مسیر را می‌خواند. اگر یکی \u003Ccode>%d\u002F%n\u003C\u002Fcode> و دیگری \u003Ccode>%u\u003C\u002Fcode> باشد، مسیرها از هم جدا می‌شوند.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>mailbox_command:\u003C\u002Fstrong> اگر \u003Ccode>mailbox_command\u003C\u002Fcode> تنظیم شده باشد (مثلاً \u003Ccode>dovecot-lda\u003C\u002Fcode> یا \u003Ccode>procmail\u003C\u002Fcode>)، تحویل به آن سپرده می‌شود و \u003Ccode>home_mailbox\u003C\u002Fcode> عملاً بی‌اثر است. خیلی‌ها هر دو را با هم دارند و از همین‌جا سردرگم می‌شوند.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>و یک تله‌ی ظریف که خیلی وقت‌ها ندیده می‌ماند: \u003Ccode>lmtp_save_to_detail_mailbox = yes\u003C\u002Fcode> در Dovecot. اگر این گزینه فعال باشد، پیام‌های \u003Ccode>user+tag@example.com\u003C\u002Fcode> به یک زیرپوشه می‌روند، نه به INBOX. کاربر فکر می‌کند ایمیل نیامده، در حالی که پیام داخل \u003Ccode>INBOX\u002Ftag\u003C\u002Fcode> نشسته است.\u003C\u002Fp>\n\u003Cp>در محیط‌هایی که SELinux یا AppArmor فعال است، یک لایه‌ی سوم هم اضافه می‌شود: حتی اگر مسیر درست باشد، پروفایل امنیتی ممکن است اجازه‌ی نوشتن روی \u003Ccode>\u002Fvar\u002Fvmail\u003C\u002Fcode> را ندهد و علائم دقیقاً به شکل «صندوق خالی» دیده شود. در آن حالت \u003Ccode>audit.log\u003C\u002Fcode> یا \u003Ccode>dmesg\u003C\u002Fcode> را هم چک کنید.\u003C\u002Fp>\n\u003Ch2 id=\"راه‌حل-گام‌به‌گام\">راه‌حل گام‌به‌گام\u003C\u002Fh2>\n\u003Ch3 id=\"گام-۱-کشف-لایه‌ی-تحویل\">گام ۱: کشف لایه‌ی تحویل\u003C\u002Fh3>\n\u003Cp>اول ببینید Postfix واقعاً چه مسیری را انتخاب می‌کند:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">postconf -n | grep -E \"home_mailbox|virtual_transport|mailbox_command|virtual_mailbox_base|virtual_mailbox_maps\"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>سه حالت رایج را می‌بینید. اگر \u003Ccode>virtual_transport = lmtp:unix:private\u002Fdovecot-lmtp\u003C\u002Fcode> است، کل تحویل به Dovecot سپرده شده و Postfix خودش به دیسک دست نمی‌زند. اگر \u003Ccode>virtual_transport = virtual\u003C\u002Fcode> است، Postfix خودش می‌نویسد. اگر \u003Ccode>mailbox_command\u003C\u002Fcode> تنظیم شده، یک LDA جدا وسط ماجراست و باید در همان مسیر مورد توافق هر دو طرف بنویسد.\u003C\u002Fp>\n\u003Ch3 id=\"گام-۲-dovecot-چه-مسیری-را-انتظار-دارد\">گام ۲: Dovecot چه مسیری را انتظار دارد؟\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-bash\">doveconf -n | grep -E \"mail_location|mail_home|mail_uid|mail_gid\"\ndoveadm user ali@example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>دستور \u003Ccode>doveadm user\u003C\u002Fcode> مستقیماً home و mail_location را نشان می‌دهد. یک نمونه خروجی:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">userdb:\n  ali@example.com\n  home: \u002Fvar\u002Fvmail\u002Fexample.com\u002Fali\n  mail: maildir:\u002Fvar\u002Fvmail\u002Fexample.com\u002Fali\u002FMaildir\n  uid: 5000\n  gid: 5000\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>این خروجی، مرجع شما است. هر مسیری که Dovecot اینجا اعلام می‌کند باید با مسیری که Postfix پیام را در آن می‌نشاند، یکسان باشد.\u003C\u002Fp>\n\u003Ch3 id=\"گام-۳-هم‌ترازسازی-در-حالت-virtual-users-توصیه‌شده\">گام ۳: هم‌ترازسازی در حالت virtual users (توصیه‌شده)\u003C\u002Fh3>\n\u003Cp>سالم‌ترین الگو در محیط عملیاتی این است که تحویل را به LMTP بسپارید تا Dovecot خودش مسیر را تعیین کند و امکان اختلاف از اساس حذف شود.\u003C\u002Fp>\n\u003Cp>در \u003Ccode>\u002Fetc\u002Fpostfix\u002Fmain.cf\u003C\u002Fcode>:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">virtual_mailbox_domains = example.com\nvirtual_mailbox_maps = hash:\u002Fetc\u002Fpostfix\u002Fvmailbox\nvirtual_transport = lmtp:unix:private\u002Fdovecot-lmtp\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>در \u003Ccode>\u002Fetc\u002Fpostfix\u002Fvmailbox\u003C\u002Fcode> فقط وجود کاربر را تعریف کنید؛ خودِ مسیر را Dovecot می‌سازد:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">ali@example.com    example.com\u002Fali\u002F\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>سپس:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">postmap \u002Fetc\u002Fpostfix\u002Fvmailbox\nsystemctl reload postfix\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>در سمت Dovecot، فایل \u003Ccode>\u002Fetc\u002Fdovecot\u002Fconf.d\u002F10-mail.conf\u003C\u002Fcode>:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">mail_location = maildir:\u002Fvar\u002Fvmail\u002F%d\u002F%n\u002FMaildir\nmail_uid = vmail\nmail_gid = vmail\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر userdb از SQL می‌آید، ستون home و mail را دقیقاً با همان الگو هم‌تراز کنید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">SELECT '\u002Fvar\u002Fvmail\u002F' || maildir AS home,\n       'maildir:\u002Fvar\u002Fvmail\u002F' || maildir || '\u002FMaildir' AS mail,\n       5000 AS uid, 5000 AS gid\nFROM mailbox\nWHERE username = '%u'\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3 id=\"گام-۴-هم‌ترازی-در-حالت-system-users\">گام ۴: هم‌ترازی در حالت system users\u003C\u002Fh3>\n\u003Cp>اگر کاربران واقعی سیستم هستید و می‌خواهید Maildir استفاده کنید، هر دو طرف را روی یک مسیر ثابت قفل کنید. در \u003Ccode>main.cf\u003C\u002Fcode>:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">home_mailbox = Maildir\u002F\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>در \u003Ccode>10-mail.conf\u003C\u002Fcode>:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">mail_location = maildir:~\u002FMaildir\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>برعکس، اگر مایل به استفاده از mbox هستید (که در محیط‌های تولیدی توصیه نمی‌شود)، \u003Ccode>home_mailbox\u003C\u002Fcode> را حذف کنید و مقصد پیش‌فرض \u003Ccode>\u002Fvar\u002Fmail\u002F%u\u003C\u002Fcode> را صراحتاً در Dovecot اعلام کنید. هرگز هر دو حالت را همزمان فعال نگذارید.\u003C\u002Fp>\n\u003Ch3 id=\"گام-۵-مالکیت-و-مجوزها\">گام ۵: مالکیت و مجوزها\u003C\u002Fh3>\n\u003Cp>حتی اگر مسیرها یکی باشند، مالکیت اشتباه همان علامت را می‌دهد. در حالت virtual:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">chown -R vmail:vmail \u002Fvar\u002Fvmail\nchmod -R 0700 \u002Fvar\u002Fvmail\u002Fexample.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>در حالت system users، مطمئن شوید \u003Ccode>\u002Fhome\u002Fali\u003C\u002Fcode> حداقل \u003Ccode>0711\u003C\u002Fcode> است و \u003Ccode>~\u002FMaildir\u003C\u002Fcode> متعلق به خود کاربر با \u003Ccode>0700\u003C\u002Fcode>:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">chmod 0711 \u002Fhome\u002Fali\nchown -R ali:ali \u002Fhome\u002Fali\u002FMaildir\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3 id=\"گام-۶-انتقال-پیام‌های-قدیمی-از-مسیر-قبلی\">گام ۶: انتقال پیام‌های قدیمی از مسیر قبلی\u003C\u002Fh3>\n\u003Cp>قبل از هر چیز یک بکاپ بگیرید، سپس محتوای مسیر قدیمی را با \u003Ccode>rsync\u003C\u002Fcode> منتقل کنید (نه \u003Ccode>mv\u003C\u002Fcode>؛ چون ممکن است همزمان نوشتن در جریان باشد):\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">systemctl stop postfix dovecot\nrsync -aHAX --info=progress2 \u002Fvar\u002Fmail\u002Fali\u002F \u002Fhome\u002Fali\u002FMaildir\u002F\nchown -R ali:ali \u002Fhome\u002Fali\u002FMaildir\nsystemctl start dovecot postfix\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر مسیر قبلی mbox بود، از ابزار تبدیل استفاده کنید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">doveadm import -u ali@example.com mbox:\u002Fvar\u002Fmail\u002Fali INBOX\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"بررسی-اینکه-مشکل-واقعا-حل-شده-است\">بررسی اینکه مشکل واقعاً حل شده است\u003C\u002Fh2>\n\u003Cp>سه سطح تست انجام دهید. سطح اول، احراز هویت و مسیر:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">doveadm auth test ali@example.com\ndoveadm user ali@example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>سطح دوم، خودِ صندوق:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">doveadm mailbox list -u ali@example.com\ndoveadm search -u ali@example.com mailbox INBOX ALL\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر تعداد پیام‌ها در خروجی \u003Ccode>doveadm search\u003C\u002Fcode> با انتظار شما هم‌خوانی داشت، سطح سوم: یک ایمیل آزمایشی بفرستید و لاگ‌ها را رصد کنید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">swaks --to ali@example.com --from test@example.com --server 127.0.0.1\ntail -f \u002Fvar\u002Flog\u002Fmail.log \u002Fvar\u002Flog\u002Fdovecot.log\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>در لاگ Postfix انتظار دارید ببینید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">status=sent (250 2.0.0 <ali@example.com> Saved)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>و بلافاصله پس از آن در Dovecot:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">lmtp(ali@example.com): ...: msgid=<...>: saved mail to INBOX\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر خط «saved mail to INBOX» را دیدید، کار تمام است. حالا با یک کلاینت IMAP واقعی وارد شوید و مطمئن شوید پیام دیده می‌شود. اگر کاربر از دو کلاینت استفاده می‌کند (مثلاً webmail و موبایل) و یکی خالی است، احتمالاً یکی از کلاینت‌ها با \u003Ccode>+detail\u003C\u002Fcode> یا با پیشوند متفاوت وصل می‌شود. یک بار جست‌وجو را روی همه‌ی پوشه‌ها بزنید تا ببینید پیام دقیقاً کجا نشسته است:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">doveadm search -u ali@example.com mailbox '*' ALL\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"پیشگیری-و-بهترین-روش‌ها\">پیشگیری و بهترین روش‌ها\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>یک منبع حقیقت انتخاب کنید.\u003C\u002Fstrong> در محیط با کاربران مجازی، LMTP تنها منبع حقیقت است. Postfix نباید هیچ‌گاه مستقیماً به دیسک بنویسد. این کار اختلاف مسیر را از اساس حذف می‌کند.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>mail_location را در IaC تست کنید.\u003C\u002Fstrong> یک تسک ادواری با Ansible یا Puppet که \u003Ccode>doveadm user\u003C\u002Fcode> را برای چند کاربر نمونه اجرا و خروجی را با مسیر تحویل مورد انتظار مقایسه کند، این تله را همان روز کشف می‌کند، نه بعد از یک هفته سکوت.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>تست smoke پس از نصب و مهاجرت.\u003C\u002Fstrong> یک اسکریپت با \u003Ccode>swaks\u003C\u002Fcode> که ایمیلی بفرستد و بلافاصله با \u003Ccode>doveadm search\u003C\u002Fcode> وجودش را تأیید کند، به شما سیگنال قطعی می‌دهد؛ نه «به نظر می‌رسد کار می‌کند».\u003C\u002Fli>\n\u003Cli>\u003Cstrong>از تعارض پیکربندی پرهیز کنید.\u003C\u002Fstrong> اگر \u003Ccode>mailbox_command\u003C\u002Fcode> تنظیم شده، \u003Ccode>home_mailbox\u003C\u002Fcode> عملاً بی‌اثر است و فقط ذهن را گمراه می‌کند. یکی را حذف کنید.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>پیش از سوییچ DNS، مسیرها را در staging همگام کنید.\u003C\u002Fstrong> تغییر پیش‌فرض \u003Ccode>mail_location\u003C\u002Fcode> در نسخه‌های جدید Dovecot یک سورپرایز بی‌صداست.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>مالکیت و مجوزها را جزو پیکربندی حساب کنید.\u003C\u002Fstrong> بخش زیادی از خطاهای «صندوق خالی» در واقع \u003Ccode>Permission denied\u003C\u002Fcode> روی \u003Ccode>~\u002FMaildir\u003C\u002Fcode> هستند که فقط به شکل خالی‌بودن خود را نشان می‌دهند؛ \u003Ccode>audit.log\u003C\u002Fcode> و SELinux را هم فراموش نکنید.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>خلاصه‌ی حرف: وقتی Postfix می‌گوید «delivered»، کار تمام نشده است. تا وقتی Dovecot همان مسیر را نبیند، کاربر هیچ‌چیز نمی‌بیند. با LMTP تحویل بدهید، mail_location را ثابت و صریح نگه دارید و تحویل end-to-end را در استیجینگ تست کنید — نه با حدس.\u003C\u002Fp>",[31,35,38,41,45,48,51,54,57,60,63],{"id":32,"text":33,"level":34},"مسئله-ایمیل-تحویل-داده-شد-ولی-صندوق-خالی-است","مسئله: ایمیل «تحویل داده شد»، ولی صندوق خالی است",2,{"id":36,"text":37,"level":34},"علت-ریشه‌ای-دو-جفت-کلید-که-با-هم-هماهنگ-نیستند","علت ریشه‌ای: دو جفت کلید که با هم هماهنگ نیستند",{"id":39,"text":40,"level":34},"راه‌حل-گام‌به‌گام","راه‌حل گام‌به‌گام",{"id":42,"text":43,"level":44},"گام-۱-کشف-لایه‌ی-تحویل","گام ۱: کشف لایه‌ی تحویل",3,{"id":46,"text":47,"level":44},"گام-۲-dovecot-چه-مسیری-را-انتظار-دارد","گام ۲: Dovecot چه مسیری را انتظار دارد؟",{"id":49,"text":50,"level":44},"گام-۳-هم‌ترازسازی-در-حالت-virtual-users-توصیه‌شده","گام ۳: هم‌ترازسازی در حالت virtual users (توصیه‌شده)",{"id":52,"text":53,"level":44},"گام-۴-هم‌ترازی-در-حالت-system-users","گام ۴: هم‌ترازی در حالت system users",{"id":55,"text":56,"level":44},"گام-۵-مالکیت-و-مجوزها","گام ۵: مالکیت و مجوزها",{"id":58,"text":59,"level":44},"گام-۶-انتقال-پیام‌های-قدیمی-از-مسیر-قبلی","گام ۶: انتقال پیام‌های قدیمی از مسیر قبلی",{"id":61,"text":62,"level":34},"بررسی-اینکه-مشکل-واقعا-حل-شده-است","بررسی اینکه مشکل واقعاً حل شده است",{"id":64,"text":65,"level":34},"پیشگیری-و-بهترین-روش‌ها","پیشگیری و بهترین روش‌ها",[67,70,72,75,77],{"name":68,"slug":69},"Postfix","postfix",{"name":71,"slug":71},"dovecot",{"name":73,"slug":74},"mail-server","mail-server-2",{"name":76,"slug":76},"lmtp",{"name":78,"slug":78},"imap",[80,83,86],{"question":81,"answer":82},"چرا با وجود اینکه در mail.log نوشته شده delivered، کاربر ایمیل را در IMAP نمی‌بیند؟","چون تحویل و نمایش دو لایه‌ی جداست. Postfix پیام را در مسیری می‌نویسد و Dovecot مسیر دیگری را برای IMAP می‌خواند. با doveadm user بفهمید Dovecot چه home و mail_location‌ای انتظار دارد و آن را با مسیر واقعی تحویل هم‌تراز کنید.",{"question":84,"answer":85},"تفاوت mbox و Maildir چیست و کدام را انتخاب کنم؟","mbox همه‌ی پیام‌ها را در یک فایل نگه می‌دارد و در محیط‌های پرترافیک باعث قفل‌شدن و ریسک خرابی می‌شود. Maildir هر پیام را در یک فایل جدا می‌گذارد، سازگاری بهتری با IMAP و ابزارهای موازی دارد و برای سرورهای امروزی انتخاب پیش‌فرض است.",{"question":87,"answer":88},"چطور بفهمم Dovecot مسیر صندوق را کجا در نظر گرفته است؟","با doveadm user ali@example.com که مستقیماً home و mail_location را چاپ می‌کند. برای بررسی فولدرها هم از doveadm mailbox list و doveadm search استفاده کنید تا ببینید پیام‌ها دقیقاً در کدام مسیر نشسته‌اند.",[90,91,92],"mail-server-self-hosted","managed-devops","nextcloud-self-hosted",true,"وقتی Postfix می‌گوید delivered but Inbox خالی است؛ علت اختلاف مسیر تحویل و mail_location در Dovecot است. راه‌حل گام‌به‌گام و دستورهای بررسی.",[96,108,121],{"id":97,"title":98,"slug":99,"excerpt":100,"cover":101,"category":103,"author":104,"track":105,"level":106,"reading_minutes":26,"is_featured":27,"published_at":107,"updated_at":107},42,"کران Nextcloud در Docker: چرا جاب‌های پس‌زمینه اجرا نمی‌شوند","nextcloud-docker-cron-background-jobs","هشدار «Last background job execution ran...» در Nextcloud Docker اغلب از اجرا نشدن cron.php داخل کانتینر است. مسیر، کاربر و حالت cron را درست می‌کنیم.",{"url":102,"alt":98},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F0ac03659-116f-46ee-9c7c-9e8e8107d8eb.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},"2026-11-12T06:15:27+00:00",{"id":109,"title":110,"slug":111,"excerpt":112,"cover":113,"category":115,"author":116,"track":117,"level":118,"reading_minutes":119,"is_featured":27,"published_at":120,"updated_at":120},13,"رفع خطای no SASL authentication mechanisms در Postfix","postfix-dovecot-sasl-auth-socket-chroot","وقتی smtpd پورت ۵۸۷ با خطای «no SASL authentication mechanisms» بالا نمی‌آید، ریشه معمولاً سوکت Dovecot است که داخل chroot پست‌فیکس ساخته نشده. این مقاله علت و راه‌حل کامل را قدم‌به‌قدم بررسی می‌کند.",{"url":114,"alt":110},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002Ffb649a07-b046-4b39-a1f9-84734bc4883e.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},6,"2026-10-15T13:00:17+00:00",{"id":122,"title":123,"slug":124,"excerpt":125,"cover":126,"category":128,"author":129,"track":130,"level":131,"reading_minutes":119,"is_featured":27,"published_at":132,"updated_at":132},8,"رفع dkim=none در Postfix با راه‌اندازی OpenDKIM","postfix-opendkim-dkim-signing-fix","اگر ایمیل‌های سرور Postfix شما در Gmail به اسپم می‌روند و هدر پیام dkim=none نشان می‌دهد، یعنی هیچ امضای DKIM روی پیام‌ها درج نمی‌شود. در این مقاله OpenDKIM را نصب، پیکربندی و به Postfix وصل می‌کنیم و رکورد DNS را منتشر می‌کنیم.",{"url":127,"alt":123},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F1b1288db-c0ed-41f3-8ee5-01f7b997c11d.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},"2026-10-09T13:30:31+00:00"]