Inkommande e-post: svar på kampanjer

När en mottagare trycker Svara på en kampanj-e-post kommer svaret tillbaka till WeZend och landar i inkorgen — trådat på samma samtal som allt annat du har skickat till den adressen, och korrelerat till exakt den kampanjen och exakt det meddelande som besvarades. E-post blir tvåvägs, som SMS och WhatsApp redan var.

Hur korreleringen fungerar

Varje kampanj-e-post stämplas med en Reply-To per meddelande på formen reply+<meddelande-id>@reply.dittforetag.se (VERP). Token är meddelandets eget UUID, så när svaret kommer in gissas inget utifrån adress och närhet i tid: id:t löses deterministiskt till en kund, en kampanj och ett ursprungligt meddelande.

Två regler håller det förutsägbart:

• Endast kampanj-utskick stämplas — ett transaktionellt POST /v1/messages/send lämnas orört.
• Ett explicit reply_to på utskicket vinner alltid. Sätter du det rör WeZend det inte, så svaret går till din egen brevlåda i stället och inget landar i inkorgen.

Vad som händer med ett svar

1. Den mottagande transporten parsar MIME-meddelandet och POSTar det till POST /v1/webhooks/inbound-email — autentiserat med delad hemlighet, samma konvention som leveransrapport-webhookarna.
2. Svaret köas för hållbar bearbetning och dedupliceras på sitt Message-ID, så en leverantör som re-POSTar samma mail inte kan skapa en dubblett. Är kön otillgänglig bearbetar webhooken svaret inline i stället för att slänga det, och endpointen svarar alltid 2xx så att leverantören aldrig hård-retryar.
3. Svaret trådas in i samtalet för den adressen och lagras med ämne, HTML-body, SPF/DKIM/DMARC-utfallen och id:t för den kampanj det besvarar.
4. En message.received-plattformshändelse avfyras, så ditt CRM eller din helpdesk får svaret utan polling. Har du satt en inkommande webhook-URL vidarebefordras svaret även dit.

Vad som sorteras bort innan det når dig

• Spam och autentiseringsfel — en spam-score på 8 eller högre, eller DMARC fail, sätts i karantän och blir aldrig en kontakt eller ett samtal.
• Autosvar — allt med en Auto-Submitted-header annan än no (frånvarosvar, ärendebekräftelser) ignoreras, så svar inte kan loopa.
• Mail som inte kan tillskrivas — en svarsadress utan giltig meddelande-token, eller en token som inte matchar något meddelande, avvisas i stället för att gissas.

Ett svar som bara lyder STOP (eller unsubscribe, afmeld, framelding …) hanteras som en avanmälan innan det blir ett supportärende: adressen hamnar på spärrlistan, ett samtyckesregister skrivs, och contact.unsubscribed avfyras — se Samtycke.

Bilagor

Bilagor lagras per svar: JPEG, PNG, GIF, WebP och PDF, upp till 15 MB per fil och 20 filer per meddelande. Andra innehållstyper registreras som överhoppade i stället för att sparas.

Varje bilaga strömmas till ClamAV (clamd, via dess INSTREAM-kommando) innan något rör disken — filen skannas i minnet, och bara ett rent utfall skrivs. Beslutet är fail-closed: en infekterad fil registreras som skipped: "virus", och är clamd onåbar, felar eller timeoutar registreras filen som skipped: "scan_unavailable" och en operatörsvarning utlöses. En skanning som aldrig returnerar ett utfall behandlas aldrig som ren, så ett skannerbortfall kan inte tyst falla tillbaka på att lagra oskannade tredjepartsfiler. Själva svaret landar fortfarande i inkorgen — det är bara filen som hålls tillbaka.

Lagrade filer är inte publika. De hämtas endast via GET /v1/media/inbound/:name, som kräver en dashboard-session och härleder sökvägen på disk från anroparens eget customer_id, aldrig från URL:en — så ett ogissbart filnamn är inte längre det enda skyddet, och en kund kan aldrig hämta en annans fil. Namnet valideras mot ett fast mönster (16 hex-tecken plus en tillåten filändelse) och path traversal strippas. Varje nedladdning tvingas med Content-Disposition: attachment och X-Content-Type-Options: nosniff, så en skadlig PDF från en extern avsändare inte kan renderas inline på ett wezend.com-origin, och Cache-Control: private, no-store hindrar en fil som senare visar sig skadlig från att ligga kvar längre ner i kedjan. Den publika /media-mounten svarar 404 på allt under inbound/. Kampanjbilder förblir publika — e-postklienter måste kunna hämta dem utan session — och tredjepartsmail är medvetet det motsatta fallet.

Skanning är en del av operatörsuppsättningen, på samma sätt som DNS:en nedan: clamd kopplas in på backenden (CLAMAV_SOCKET, eller CLAMAV_HOST/CLAMAV_PORT) innan inkommande e-post slås på. Är ingen skanner konfigurerad lagras bilagor och registreras med scanned: false — den vägen finns för dev- och test-byggen, inte för en domän som tar emot verklig extern e-post.

Så slår du på det

Inkommande e-post ligger i vila tills en operatör konfigurerar det — det finns ingen knapp i dashboarden, eftersom det kräver DNS. Uppsättningen är en MX-post på en dedikerad svars-subdomän (till exempel reply.dittforetag.se) som pekar på den mottagande transporten, plus den domänen satt på backenden. Apex-domänens befintliga MX är orörd, så detta stör inte var företagets brevlådor bor i dag.

I praktiken är det SendGrid Inbound Parse: svars-subdomänens MX pekar på den, den utvärderar SPF, DKIM och DMARC, och den POSTar det parsade meddelandet till ingestion-endpointen. Er DNS ligger kvar där den redan är — posten är en MX på en subdomän, inte en migrering.

Transporten hålls medvetet på armlängds avstånd: ingestion-endpointen normaliserar det den tar emot till en intern payload, så att byta eller lägga till en mottagande leverantör är en mappare, inte en omskrivning. Den utgående uppsättningen är oförändrad — se E-post: domäner, DNS & utskick.