Innkommende e-post: svar på kampanjer

Når en mottaker trykker Svar på en kampanje-e-post, kommer svaret tilbake til WeZend og lander i innboksen — trådet på samme samtale som alt annet du har sendt til den adressen, og korrelert til nøyaktig den kampanjen og nøyaktig den meldingen det ble svart på. E-post blir toveis, slik SMS og WhatsApp allerede var.

Hvordan korreleringen virker

Hver kampanje-e-post stemples med en Reply-To per melding på formen reply+<melding-id>@reply.dittfirma.no (VERP). Tokenet er meldingens eget UUID, så når svaret kommer inn, gjettes ingenting ut fra adresse og tidsnærhet: id-en løses deterministisk til én kunde, én kampanje og én opprinnelig melding.

To regler holder det forutsigbart:

• Bare kampanje-sendinger stemples — en transaksjonell POST /v1/messages/send røres ikke.
• En eksplisitt reply_to på sendingen vinner alltid. Setter du den, lar WeZend den være, så svaret går til din egen postkasse i stedet og ingenting lander i innboksen.

Hva som skjer med et svar

1. Den mottakende transporten parser MIME-meldingen og POSTer den til POST /v1/webhooks/inbound-email — autentisert med delt hemmelighet, samme konvensjon som leveringsrapport-webhookene.
2. Svaret køes for holdbar behandling og dedupliseres på sitt Message-ID, så en leverandør som re-POSTer samme e-post ikke kan lage en dublett. Er køen utilgjengelig, behandler webhooken svaret inline i stedet for å forkaste det, og endepunktet svarer alltid 2xx slik at leverandøren aldri hard-retryer.
3. Svaret trådes inn i samtalen for den adressen og lagres med emne, HTML-body, SPF/DKIM/DMARC-verdiktene og id-en til kampanjen det svarer på.
4. En message.received-plattformhendelse avfyres, så CRM-et eller helpdesken din får svaret uten polling. Har du satt en innkommende webhook-URL, videresendes svaret dit også.

Hva som lukes ut før det når deg

• Spam og autentiseringsfeil — en spam-score på 8 eller høyere, eller DMARC fail, settes i karantene og blir aldri en kontakt eller en samtale.
• Autosvar — alt med en Auto-Submitted-header annet enn no (ferie-svar, sakskvitteringer) ignoreres, så svar ikke kan loope.
• E-post som ikke kan tilskrives — en svaradresse uten gyldig meldings-token, eller et token som ikke matcher noen melding, avvises heller enn å bli gjettet på.

Et svar som bare lyder STOP (eller unsubscribe, afmeld, framelding …) håndteres som en avmelding før det blir en supportsak: adressen havner på sperrelisten, en samtykkeregistrering skrives, og contact.unsubscribed avfyres — se Samtykke.

Vedlegg

Vedlegg lagres per svar: JPEG, PNG, GIF, WebP og PDF, opp til 15 MB per fil og 20 filer per melding. Andre innholdstyper registreres som hoppet over heller enn å bli lagret.

Hvert vedlegg strømmes til ClamAV (clamd, via INSTREAM-kommandoen) før noe rører disken — filen skannes i minnet, og bare et rent verdikt blir skrevet. Beslutningen er fail-closed: en infisert fil registreres som skipped: "virus", og er clamd utilgjengelig, feiler eller går på timeout, registreres filen som skipped: "scan_unavailable", og et operatørvarsel utløses. En skanning som aldri returnerer et verdikt, behandles aldri som ren, så et skannerbortfall kan ikke stille falle tilbake på å lagre uskannede tredjepartsfiler. Selve svaret lander fortsatt i innboksen — det er bare filen som holdes tilbake.

Lagrede filer er ikke offentlige. De lastes bare ned via GET /v1/media/inbound/:name, som krever en dashbord-sesjon og utleder stien på disk fra kallerens eget customer_id, aldri fra URL-en — så et ugjettelig filnavn er ikke lenger den eneste beskyttelsen, og én kunde kan aldri hente en annens fil. Navnet valideres mot et fast mønster (16 hex-tegn pluss en tillatt filendelse), og path traversal strippes. Hver nedlasting tvinges med Content-Disposition: attachment og X-Content-Type-Options: nosniff, slik at en ondsinnet PDF fra en ekstern avsender ikke kan rendres inline på et wezend.com-origin, og Cache-Control: private, no-store hindrer at en fil som senere viser seg ondsinnet blir liggende lenger ned i kjeden. Det offentlige /media-mountet svarer 404 på alt under inbound/. Kampanjebilder forblir offentlige — e-postklienter må kunne hente dem uten sesjon — og tredjeparts-e-post er bevisst det motsatte tilfellet.

Skanning er en del av operatøroppsettet, på samme måte som DNS-en nedenfor: clamd kobles opp på backenden (CLAMAV_SOCKET, eller CLAMAV_HOST/CLAMAV_PORT) før innkommende e-post slås på. Er ingen skanner konfigurert, lagres vedlegg og registreres med scanned: false — den veien finnes for dev- og test-bygg, ikke for et domene som tar imot reell ekstern e-post.

Slik slår du det på

Innkommende e-post ligger i dvale til en operatør konfigurerer det — det finnes ingen bryter i dashbordet, fordi det krever DNS. Oppsettet er én MX-post på et dedikert svar-subdomene (for eksempel reply.dittfirma.no) som peker på den mottakende transporten, pluss det domenet satt på backenden. Apex-domenets eksisterende MX er urørt, så dette forstyrrer ikke der firmaets postkasser bor i dag.

I praksis er det SendGrid Inbound Parse: svar-subdomenets MX peker på den, den evaluerer SPF, DKIM og DMARC, og den POSTer den parsede meldingen til ingestion-endepunktet. DNS-en deres blir der den allerede er — posten er én MX på et subdomene, ikke en migrering.

Transporten holdes bevisst på armlengdes avstand: ingestion-endepunktet normaliserer det det mottar til én intern payload, så å bytte eller legge til en mottakende leverandør er en mapper, ikke en omskriving. Det utgående oppsettet er uendret — se E-post: domener, DNS & utsending.