e376b571be
tests / pest (push) Failing after 7m59s
Details
tests / assets (push) Successful in 20s
Details
tests / release (push) Has been skipped
Details
No, not an API token: mailcow's API administers domains and mailboxes — it does not read mail. Reading a mailbox is IMAP whoever runs the server, so that is what this is. Host, user and folder are console settings; the password is a vault entry, like every other credential that opens something. IMAP by hand rather than a dependency. Four verbs are needed — LOGIN, SELECT, SEARCH UNSEEN, FETCH — and the parsing that follows is the real work either way. It is bounded by what the console shows: a sender, a subject, the words a person wrote, and the NAMES of anything attached. Real mail from real people arrives encoded, so it handles RFC 2047 subjects (every German subject with an umlaut in it), quoted-printable and base64 bodies, Windows charsets, and multipart — text wins over HTML, because a console is not a mail client and the words are in the text part. A message it cannot make sense of is skipped and logged, never guessed at: a garbled question in front of an operator is worse than one they go and read in the mailbox, where it still is. ATTACHMENTS ARE NOT STORED. Only their names and sizes, so an operator knows something was attached and can go and look if it matters. Keeping whatever a stranger chooses to send would make this application a malware store with a web interface in front of it. Whose a mail is, is decided by the sender's ADDRESS and by nothing else — not by a name in the subject, not by anything in the body. A mail is easy to write and this decision attaches a stranger's words to a real customer's file; there is a test that forges the name and the subject and still gets nothing. An address nobody recognises stays unassigned, shown FIRST and never hidden: that is a new enquiry, or a customer writing from their private account, and it is the mail that must not be missed. An operator can place it by hand from the same row. Nothing is deleted on the mail server, ever. Messages are flagged seen once the row is safely written — and only then, because flagging first and failing after would lose the message with no second copy anywhere. Filing one away is this console's own state; the mailbox is untouched. Two fixes on the way past: the customer page printed "customers.status.active" and "support.status.open" — a lang key with no file behind it renders as itself and Laravel says nothing — and the same page is now covered by a test proving each list is scoped to the customer in the URL, which was reported as "unterhalb steht immer das selbe". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| Admin | ||
| Auth | ||
| Concerns | ||
| Backups.php | ||
| Billing.php | ||
| Cloud.php | ||
| ConfirmBookStorage.php | ||
| ConfirmCancelAddon.php | ||
| ConfirmCancelPackage.php | ||
| ConfirmCloseAccount.php | ||
| ConfirmDisableTwoFactor.php | ||
| ConfirmEndOtherSessions.php | ||
| ConfirmRemoveOrder.php | ||
| ConfirmRestartCloud.php | ||
| ConfirmRevokeSeat.php | ||
| ConfirmWithdraw.php | ||
| CustomDomain.php | ||
| CustomerProvisioning.php | ||
| Dashboard.php | ||
| EditMailbox.php | ||
| EditSeat.php | ||
| Invoices.php | ||
| NewSupportRequest.php | ||
| Order.php | ||
| Sessions.php | ||
| Settings.php | ||
| Support.php | ||
| Users.php | ||