En opskrift til en kodeagent
Hvis du vil skrive programmet selv
MailSync holder en lokal maildatabase og en IMAP-konto enige. Det kræver sikker identitet for hver mail, en varig journal for lokale ændringer og et tydeligt stop, når udfaldet er tvetydigt.
Her er hele funktionskontrakten på én side. Vælg selv implementeringssprog. Byg ikke skrivehandlingerne, før den skrivebeskyttede gennemgang kan verificeres mod en testkonto.
1. Opgaven og grænserne
- Byg et selvstændigt kommandolinjeprogram til Linux, macOS og Windows. Det skal kunne bruge flere konti og give hver konto en separat fillås, så kun én proces ejer dens synkroniseringstilstand.
- En konto har tilstanden
fetchellersync.fetchgemmer rå EML-filer fra konfigurerede mapper og sender aldrig skrivekommandoer.syncopbygger en lokal SQLite-database med beskeder, mapper, placeringer, flag, rå MIME-data, udtrukket tekst og en operationsjournal. - En lokal webklient må læse databasen og anmode om ændringer gennem journalen. MailSync er ikke en mailbrugerflade, SMTP-klient eller en server, der modtager brugerens mail.
- Synkronisér nye mails, mappeplaceringer, læst-status, flytninger og sletninger. Arkivér en kopi i IMAP Sendt, når en særskilt SMTP-komponent har bekræftet præcis hvilke MIME-bytes der blev sendt. Et uafklaret SMTP-forsøg må ikke automatisk arkiveres eller sendes igen.
2. Konfiguration, data og identitet
Læs en privat JSON-konfiguration via --config PATH. Den indeholder absolut state_dir, et interval på mindst 60 sekunder og én eller flere konti med unikt ID, mode, IMAP-vært, port, TLS, brugernavn, godkendelsesmetode og database eller destinationsmapper. En sync-konto kræver absolut SQLite-sti. En fetch-konto kræver mindst én fjernmappe og en absolut lokal destinationsmappe. Afvis ugyldige, manglende eller usikre værdier før netværksforbindelse.
{
"state_dir": "/home/user/.local/state/mailsync",
"poll_interval_seconds": 300,
"accounts": [{
"id": "personal",
"mode": "sync",
"database": "/home/user/private/mail.sqlite3",
"host": "imap.example.com",
"port": 993,
"tls": "implicit",
"username": "user@example.com",
"auth": "password",
"password": "APP_PASSWORD"
}]
}
Brug TLS med certifikatkontrol før login. Understøt password, Google OAuth og Microsoft OAuth. Gmail bruger imap.gmail.com og https://mail.google.com/; Microsoft bruger outlook.office365.com og delegeret IMAP-adgang. Gem refresh tokens privat, verificér at tokenet hører til den konfigurerede konto og klient, og stop med krav om ny godkendelse, hvis det er tilbagekaldt.
Den varige identitet for en kopi på serveren er konto + mappe + UIDVALIDITY + UID. Message-ID og ens MIME-indhold kan hjælpe med afstemning, men må ikke erstatte denne nøgle. Gem rå MIME-data uden omskrivning. En mail kan have flere placeringer; bevar relationen mellem den lokale besked og hver serverplacering.
Databasen skal mindst have poster for kontoens kontroltilstand, IMAP-mapper med special-use og UIDVALIDITY, beskeder med rå MIME og tekst, placeringer med UID og flag, samt en operationsjournal. Brug SQLite-transaktioner, WAL, foreign keys og privat filadgang. Gem lokale brugerændringer og deres journalposter i samme transaktion.
3. IMAP-læsning og afstemning
- Læs serverens
CAPABILITYogLIST. Afkod IMAP-mappenavne korrekt, spring\Noselectover, og registrér\Sent,\Trash,\Junk,\Draftsog\Archivefra SPECIAL-USE. En manglende eller tvetydig specialmappe stopper kun de handlinger, der kræver den. - Åbn mapper skrivebeskyttet under inventar. Gem UIDVALIDITY, UID'er og flag. Hent nye meddelelser med
BODY.PEEK[], verificér literalens længde og gem original MIME før placeringen registreres som gennemført. - Første gennemgang etablerer en baseline. Den må ikke tolke fravær på serveren som en lokal sletteordre. Ved efterfølgende gennemgange skal serverændringer først registreres lokalt; lokale ønsker må ikke stiltiende overskrive dem.
- Hvis UIDVALIDITY ændres, stop synkroniseringen og kræv manuel identitetsafstemning. Tidligere UID'er må aldrig bruges til IMAP-skrivekommandoer i den nye sekvens.
4. Operationsjournalen
En lokal anmodning har et stabilt request-key, konto, lokal besked-ID, handling, forventet kildemappe, UIDVALIDITY og UID, mål og status. Gentaget request-key med samme indhold giver samme operation; genbrug med andet indhold er en fejl. Status skal mindst kunne skelne pending, inflight, ambiguous og done.
Understøt move, seen, delete og en intern append_sent. Læs den aktuelle serveridentitet igen før hver handling. move bruger IMAP MOVE og kræver en verificerbar COPYUID-kvittering for den nye placering. delete skal være UID-baseret og først afsluttes efter bekræftet sletning. Bevar råmail og tombstone indtil da. seen ændrer kun det forventede flag på den forventede UID. append_sent skal sende de præcise MIME-bytes til entydig Sendt-mappe og kræve APPENDUID eller en sikker afstemning.
Et netværksbrud efter afsendt kommando kan betyde, at serveren udførte den. Markér derfor operationen ambiguous og stop senere skrivning for kontoen, indtil udfaldet er afklaret. Gentag ikke blindt en flytning, sletning eller Sent-kopi. En ældre uafklaret operation på samme mail blokerer nyere operationer.
5. Kommandoer og aktivering
Implementér authorize, inventory, stage, activate, once, run, status og queue med --config PATH og valgfrit --account ID. queue modtager besked-ID, handling, mål og unikt request-key. once kører én afstemning, run gentager med intervallet. Udskriv maskinlæsbar JSON-status pr. konto og fejlstatus, hvis mindst én konto fejler; fejl på én konto må ikke springe de andre over.
inventoryopbygger og viser baseline uden IMAP-skrivning.- Brugeren gennemgår optælling, mapper, UID'er og konflikter og tager en verificeret backup.
stagelægger eksisterende lokale mappe- og læst-valg i journalen uden at udføre dem.activatemå først åbne for skrivning, når baseline er fuldført og sidste inventar er uden fejl.onceellerrunbehandler journalen med en ejerlås og stopper ved uafklaret operation.
fetch-konti får aldrig skriveadgang gennem aktivering. For en ny IMAP-udbyder skal MOVE, UID-baseret sletning og Sent-kopi prøves på en isoleret testkonto, før produktionsmail bruges.
6. Stopkriterier og accept
Stop skrivehandlinger, hvis en mappe ikke kan identificeres, serveren mangler nødvendig capability, UID eller UIDVALIDITY er ændret, en operation har ukendt udfald, der findes uafstemte sletninger, eller en verificeret backup mangler. Skriv aldrig passwords, tokens eller mailindhold i loggen. Lokale database-, tilstands- og tokenfiler skal være private. Tag SQLite-backup med backup-API'et eller under en pause i synkroniseringen.
- En gentaget inventarkørsel uden ændringer giver samme antal beskeder og placeringer.
- Flytning, læst-status og sletning opdaterer både IMAP og lokal placering præcist én gang efter bekræftelse.
- Et afbrudt MOVE eller APPEND bliver
ambiguous; næste kørsel udfører det ikke igen automatisk. - Skift af UIDVALIDITY, to konkurrerende processer og en tvetydig specialmappe stopper sikkert.
- En
fetch-konto sender ingen IMAP-skrivekommandoer. Ensync-konto sender ingen før eksplicit aktivering.