پایگاه دانش
صندوق قدیمیتان را بیاورید
با همان نامههایی که از پیش دارید وارد شوید، چه بایگانیای که از جای فعلیشان خروجی گرفته شده و چه خودِ حساب، با همان رشتهبندی پیشین و بایگانیشده در جای درست.
هنوز نه
هنوز هیچ درونریزی از هیچ نوعی وجود ندارد؛ تنها بخشی که از پیش حل شده رشتهبندی است، چون نامهٔ درونریزیشدهای که هدرهای اصلیاش را نگه دارد، خودش در کنار نامههایی که بعداً میرسند رشته میشود.
جزئیات
- عرضه نشده است. هیچچیز اینجا mbox، فایل .eml، بایگانی یک ارائهدهنده یا حساب IMAP را نمیخواند، و صفحهای برای آغاز درونریزی وجود ندارد. تجزیهگری که این خواندن را انجام میدهد از پیش یک وابستگی است و از پیش روی هر پیامی که میرسد اجرا میشود؛ آنچه وجود ندارد چیزی است که بایگانی را به پیامها بشکند و به آن تجزیهگر بسپارد.
- رشتهبندی اصلاً به کار تازهای نیاز ندارد. گفتوگو روی نخستین ورودی هدر References یک پیام لنگر میاندازد، و اگر نبود روی In-Reply-To و سپس روی شناسهٔ خودِ پیام؛ همان قاعدهای که هر سامانهٔ ایمیل دیگری به کار میبرد، پس درونریزیای که این سه هدر را حفظ کند رشتهها را دقیقاً بازتولید میکند، بدون جدول نگاشت شناسه و بدون گذر دوم. نامهٔ درونریزیشده سپس با نامههایی که بعداً میرسند در یک رشته قرار میگیرد، چون هر دو از همان تابع میگذرند.
- مسیر تحویل قابل استفادهٔ دوباره است و بیشتر کارهایی که میکند باید خاموش شوند. پیامی که میرسد برای فیشینگ امتیاز میگیرد، از نظر نگارش با هوش مصنوعی بررسی میشود، خلاصه میشود، برای جستوجو embedding میگیرد، برای فایلها نمایه میشود و به هر تب باز پخش میشود. هشتاد هزار پیام قدیمی را از آن بگذرانید و میشود هشتاد هزار فراخوان مدل و هشتاد هزار اعلان؛ پس درونریز جایش کنار مسیر صندوق یکبارمصرف است که از پیش بهعنوان نمونهٔ یک ورودِ عمداً خاموش وجود دارد، نه بهعنوان کلید پنجمِ مسیر تحویل.
- نامهٔ قدیمی نباید در صندوق ورودی بنشیند. پوشه در اینجا فقط یک برچسب است و بس، پس بایگانی کردن هشت سال نامه یعنی نوشتن ARCHIVE بهجای INBOX و UNREAD. کلیدی که امروز این کار را میکند، بهعنوان عارضهٔ جانبی همبستهسازی گزارشهای تحویل را هم سرکوب میکند، پس درونریزی به کلید خودش نیاز دارد نه به قرض گرفتن آن. تاریخها از روی خود پیام برداشته میشوند، پس رشتهای از 2019 بهعنوان 2019 مرتب میشود نه بهعنوان روزی که جابهجا شدهاید.
- اجرای دوبارهٔ همان درونریزی نباید صندوق را دوبرابر کند. پیامها از پیش بر اساس جفتِ شناسهٔ پیام و فرستنده حذفِ تکراری میشوند، نه بر اساس شناسهای که اینجا تولید شده باشد، پس اجرای دوباره پس از یک شکست ذاتاً امن است، و همین است که اصلاً درونریزیِ ازسرگیریپذیر را ممکن میکند. آنچه پیرامونش کم است دفترداری است: یک رکورد کار، یک نشانگر، شماری که بتوانید تماشایش کنید و فهرستی از آنچه نیامده است.
- دو راه ورود، و اندازهشان یکی نیست. فایلی که از پیش در دست دارید به یک تجزیهگر و یک صف نیاز دارد و بس، و هر ارائهدهندهای در صورت درخواست یکی به شما میدهد. خواندن یک حساب زنده از روی API خودش به کلاینت OAuth، صفحهٔ رضایت، بازبینی و دامنهای از دسترسی نیاز دارد که برای خواندن کل یک صندوق کافی باشد، و این محصول عمداً همان دامنهٔ دسترسی را کنار گذاشته است. فایل، مسیری است که شما را با تاریخچهتان به اینجا میآورد؛ حساب، تصمیمی جداگانه است دربارهٔ اینکه چقدر دسترسی درخواست شود.