Ga direct naar de documentatie
Kennisbank

Regels die je zelf schrijft

Je eigen voorwaarden, en wat er moet gebeuren met alles wat eraan voldoet.

Details

  • Geschreven in Instellingen → Regels, en via de REST API op /rules, die voor elke workspace aanstaat. Een regel is een lijst voorwaarden over een binnenkomend bericht en een lijst acties die worden uitgevoerd op alles wat eraan voldoet: 100 regels per mailbox, elk met maximaal 20 voorwaarden en 10 acties. Dat zijn beveiligingen tegen een script in een lus, geen planlimieten. De 101e regel wordt geweigerd met een bericht dat dat zegt, niet in rekening gebracht.
  • Eenentwintig dingen waar een voorwaarde naar kan vragen: het From-adres en het domein ervan (waarbij een match op example.com ook mail.corp.example.com dekt), de SMTP-envelopafzender, To, Cc, Bcc, elke ontvanger, Reply-To, het adres waaraan de kopie daadwerkelijk is afgeleverd met de plus-tag eraf, onderwerp, body, elke benoemde header, de List-Id, de naam, het type of de grootte van een bijlage, of er überhaupt een bijlage is, de totale berichtgrootte, het spamoordeel, en het uur en de weekdag van binnenkomst in UTC. Matchen gebeurt met een glob (* en ?), of met bevat, is gelijk aan, begint met, eindigt op, en groter of kleiner dan bij de vier numerieke velden. Een patroon moet zelf twee alfanumerieke tekens bevatten, dus een kale * wordt geweigerd op het moment dat je hem schrijft in plaats van elk bericht te matchen dat ooit binnenkomt.
  • Alle voorwaarden of een willekeurige ervan, met een NOT op elke voorwaarde afzonderlijk. Er is geen geneste haakjesstructuur: (A en B) of C zijn twee regels, en zo lees je het zes maanden later toch terug.
  • Elf acties: labelen, een label verwijderen, archiveren, als gelezen markeren, met een ster markeren, als spam wegzetten, naar de prullenbak sturen, doorsturen, automatisch antwoorden vanuit een template, de afzender blokkeren, en het bericht ronduit weigeren. Regels draaien in de volgorde waarin je ze zet, het laagste nummer eerst, en elke regel kan worden uitgezet zonder te worden verwijderd. Een regel met stop processing beëindigt de doorloop, zodat niets eronder nog wordt bekeken, en als twee regels allebei een map noemen, wint de latere, want dat is wat een genummerde lijst betekent.
  • Weigeren aan de deur kan alleen op de envelop, en anders wordt het bij het opslaan geweigerd. Een 550 wordt beantwoord door wie het bericht aan ons overhandigde, en op een mailinglijst is dat de LIJST, die het leest als een bouncende abonnee en je uitschrijft van iets waarbij je alleen maar wilde dat één persoon ophield met posten. Een regel die een afzender alleen op de From-header matcht, zet het bericht in plaats daarvan onder Spam, precies zoals blokkeren dat doet.
  • Automatisch antwoorden antwoordt geen machine. Het wordt onderdrukt bij Auto-Submitted, Precedence: bulk, list of junk, een List-Id- of List-Unsubscribe-header, X-Autoreply, X-Autorespond, en bij de lege envelopafzender die elke bounce draagt. Daarnaast krijgt één afzender hooguit één antwoord per dag. Twee mailboxen met antwoordregels en zonder beveiliging mailen elkaar tot iemand het merkt.
  • Een doorstuur is een opnieuw opgebouwde kopie en niet het bericht dat binnenkwam: het gaat via het verzendpad naar buiten, dus de DKIM-handtekening van de afzender overleeft het niet, en ongebruikelijke headers en exotische onderdelen evenmin. Het origineel reist mee als .eml-bijlage, zodat de headers en de exacte onderdelen nog te lezen zijn, tenzij het boven het bijlageplafond van 5MB uitkomt; in dat geval gaat de doorstuur alsnog met de leesbare tekst en blijft het origineel achter in je eigen mailbox. Niets vertelt je dat dat is gebeurd, en dat is het deel dat het waard is om te weten. De bestemming wordt gecontroleerd wanneer je de regel schrijft, maar alleen op vorm: ops, of ops@example zonder punt, wordt geweigerd terwijl je het schrijft in plaats van daarna bij elk matchend bericht te mislukken. Een typefout die nog steeds een geldig adres oplevert ([email protected] in plaats van [email protected]) wordt geaccepteerd, en de bestemming van een regel wordt nooit om bevestiging gevraagd zoals die van een adresdoorstuur, dus de kopie gaat precies naar wat je hebt getypt.
  • Een regel kan worden uitgeprobeerd voordat hij aanstaat: richt hem op de laatste dertig dagen (tot een jaar, tot 200 berichten) en hij rapporteert welke van je eigen berichten hij zou hebben gevangen en wat hij ermee zou hebben gedaan, zonder er één aan te raken. Dezelfde matcher beantwoordt dat als degene die op het afleverpad draait, maar een opgeslagen bericht is niet het bericht dat SMTP heeft overhandigd. De envelopafzender, de headermap, de List-Id, het adres waaraan het is afgeleverd en de omvang op de lijn zijn tegen die tijd weg, dus elf van de eenentwintig velden antwoorden in een testrun anders of kunnen helemaal niet antwoorden, en het dialoogvenster noemt ze in plaats van ze stilletjes als misser te tellen. Het scherpste geval is een regel die aan de deur weigert: die moet een voorwaarde op de envelopafzender dragen, en niets in de opslag kan zo'n voorwaarde beantwoorden, dus een voorbeeld meldt dat hij niets matcht, hoeveel hij in de praktijk ook zou weigeren.
  • Niets werkt met terugwerkende kracht, en er is bewust geen knop die dat wel doet. Een regel toepassen op een mailbox die je al hebt is onbegrensd, kent geen ongedaan maken, en zou elk bericht dat hij aanraakt terugsleuren naar de bovenkant van de inbox. Regels bepalen wat er gebeurt met mail die hierna binnenkomt.
  • Wat elke regel heeft gedaan wordt per bericht vastgelegd (de acties die zijn uitgevoerd en, apart, de acties die zijn geweigerd en waarom), zodat “waarom is dit hier terechtgekomen” en “waarom heeft mijn afwezigheidsbericht daar niet op geantwoord” allebei te beantwoorden zijn. Het logboek bewaart de naam van de regel, zodat het nog steeds klopt nadat de regel is hernoemd of verwijderd.
  • Het geldt voor elk adres op je eigen domeinen, dus een regel bereikt alles wat binnenkomt in plaats van te worden aangeboden op een plek waar hij stilletjes niets zou doen.
  • Als de engine geen antwoord kan geven (een voorwaarde van een nieuwere client, een database die niet reageert), wordt het bericht afgeleverd zoals het anders ook was gegaan en wordt de fout gelogd. Een regel die een fout gooit, is een bericht dat nooit aankomt.