[php] massamail en dan bounces goed verwerken

[TromboneFreakus]

Voor de administratie van de Juridische Faculteitsvereniging Nijmegen willen we binnenkort alle, ongeveer 1500, leden een mail sturen met daarin hun gegevens. De idee is dat ze deze dan zelf online kunnen controleren en aanpassen. Tot zover niets aan de hand.

Nu voorzie ik echter al wel dat er vele mailadressen niet (meer) bestaan. Een percentage van zo'n 20% zou me, gezien de geschiedenis van die administratie, niet verbazen. Zou dat allemaal bouncen naar de secretaris, dan wordt ze gek. Belangrijk punt is echter: doe je niets met die bounces, dan blijft het probleem simpelweg bestaan.

Dus ik zoek naar een systeem om dit slim op te pakken. Zoekend met Google kom ik helaas nog niet zo ver. Op dit forum vind ik twee topics die een beetje in de buurt komen (deze en vooral deze). Vooral die laatste is echter al heel oud.

Waar ik zelf aan zat te denken is het volgende: ik stel de return path in op een bepaald vast adres dat ik als een soort 'foutmeldingen-mailbox' vooraf apart aanmaak. Deze box lees ik vervolgens uit met PHP en hierin zoek ik naar mailadressen. Ieder mailadres dat voorkomt in de tekst van deze mails wordt gezocht in de database met lidgegevens en bij iedere treffer wordt van dat lid het mailadres op niets gezet (empty string, niet null). Weliswaar levert dat ook veel zoektochten op naar adressen als postmaster@ en mail-daemon@, maar het lijkt me efficienter dan een truc verzinnen om juist die adressen uit te sluiten.

Er zijn enkele aandachtspuntjes. Op internet las ik op diverse plaatsen dat het aanpassen van het 'return-path' niet verstandig zou zijn in verband met spamfilters. Is dat ook jullie ervaring, of valt dat wel mee voor mailtjes die overigens keurig aan voornaam achternaam <mailadres> worden geadresseerd??

Verder vraag ik me af: heeft iemand zoiets al werkend ergens (gezien) en kan ik wellicht de php-code daarvan inzien? Of is een heel ander systeem wellicht veel slimmer? Overzie ik wellicht iets niet? Het idee van VERP zoals beschreven in het tweede topic waarnaar ik link klinkt goed, maar dit los volgens mij tegelijk in wezen niets op aan het probleem dat je dan nog steeds het mailadres moet distilleren uit de andere brei data.

Graag jullie blik op dit geheel. Alvast bedankt.

[Pete]

phplist van tincan heeft precies die functie die jij bedoelt

www.phplist.com


je zou iig geval bij ze kunnen kijken hoe zij dat afhandelen

[ Voor 23% gewijzigd door Pete op 24-01-2006 20:33 ]

[xtra]

Veel mailinglists gebruiken een aangepast return-path. Door ook dit uniek te maken (bounce1234@domein) kun je geautomatiseerd je bestand bijwerken. Als je verder een 'nette' mail maakt zullen veel spamfilters er geen probleem van maken. Met een paar testmailtjes via verschillende filters kun je zien wat je eventueel moet aanpassen.

Een check op de retourmailtjes is wel slim. Anders verwijder je eventueel ook de adressen waarvan de mailbox vol is.

In testvorm heb ik het zelf eens gemaakt maar dat was ASP, geen PHP. Het werkte in ieder geval prima. (als in: bounces naar adres a, replies naar adres b.)

[Bosmonster]

Zelf heb ik het ook gedaan met return-path, een speciale bounce pop-box en php om deze uit te lezen. Wel heb ik extra nog een X-header toegevoegd met het e-mailadres waarnaar verstuurd is, zodat deze er eenvoudiger uit te filteren is (anders is het zo goed als onmogelijk, aangezien iedere bounce ongeveer anders is en niet iedere ook het adres mee terug stuurt).

Wat betreft reden voor bounce... je kunt moeilijk gaan sorteren of filteren waarop iets gebounced is. Een server kan ook een hickup hebben, een mailbox tijdelijk vol, etc.

Kies dan voor een driemaal-mis-is-verwijderen feature ofzo. Als je op hetzelfde adres bij 3 mailings een bounce hebt terug gekregen, dan het adres maar verwijderen bijvoorbeeld. Zo ben je nog enigszins soepel, zonder automatisering in de weg te staan.

[ Voor 38% gewijzigd door Bosmonster op 24-01-2006 22:16 ]

[TheRookie]

als toevoeging op phsmith:
Mailing list managers hebben over het algemeen methoden om met bounces om te gaan; ik zou eerst eens bij bijvoorbeeld ezmlm of Mailman afkijken hoe zij dat afhandelen
De taal zal geen php zijn; maar het idee erachter zal er wel uit te destilleren zijn...

[ Voor 14% gewijzigd door TheRookie op 24-01-2006 22:17 ]

[martijn_brinkers]

Je 'mag' geen gebruik maken van de return-path aangezien deze door de 'final delivery' SMTP server aan het mailtje moet worden toegevoegd. Zie:

http://www.ietf.org/rfc/rfc2821.txt

Wat je moet doen is de local part van de enveloped sender (dat is dus iets anders dan de FROM header!) per recipient aanpassen. De bounce wordt dan gestuurd naar dat adres. Aangezien elke recipient een eigen enveloped sender adres heeft kan je dus herkennen op welk adres de bounce optrad. Een mogelijkheid is bijv. dat je als enveloped sender (local part) de base64 representatie neemt van de recipient. Voorbeeld:

Je server heeft als domein example.com

Je stuurt een mailtje naar [e-mail]

Base64 van [e-mail] is dan:

cGlldEBqZXB1ay5ubA==

(de == moet je nog wel encoden naar bijv __) . Je stuurt dan het mailtje met als afzender

[e-mail]

Wanneer je nou een bounce krijg dan krijg je dat op dat adres binnen. Je kan daaruit weet het originele email adres verkrijgen door Base64 te decoden. Het voordeel is dat je geen state hoeft bij te houden. Het encoden met Base64 is maar een voorbeeld. Het kan op nog meer manieren.

[Creepy]

Oftewel VERP (Variable Envelope Return Paths)? (VERP is een heerlijke google term overigens )

[Reptile209]

Misschien een beetje een omweg, maar wellicht het proberen waard: sommige mailservers geven meteen aan of een alias bestaat of niet. Open daarvoor een telnet-sessie naar de SMTP-server van het domein (hehehe... okee, doe eerst een MX-lookup) en probeer eens:

code:

HELO <je eigen IP>
MAIL FROM: <je eigen emailadres>
RCPT TO: <het te testen adres>
<wacht op reply: 200 (?) sender OK of 550 afgekeurd>
RSET
QUIT

Net even getest met mail.planet.nl (vreemde SMTP) en mail.utwente.nl (mijn eigen SMTP) met niet bestaande ontvangers. Planet geeft aan dat de alias niet bestaat (550 <foutmelding>), de UT slikt hem helaas gewoon.
Het is dus verre van dekkend, maar een script als dit zou misschien al een groot deel van de fouten kunnen onderscheppen. En daarvan hoef je dan geen bounces meer te verwerken.

Just my € 0.02...

[xtra]

TijnFLiP schreef op dinsdag 24 januari 2006 @ 22:34:
Je 'mag' geen gebruik maken van de return-path aangezien deze door de 'final delivery' SMTP server aan het mailtje moet worden toegevoegd. Zie:
(...)

Is het effect hiervan niet dat het gegenereerde adres als return-path wordt gebruikt? Deze methode heb ik namelijk min of meer gebruikt. Zelf het return-path aan je bericht toevoegen heeft meestal/altijd het gevolg dat deze wordt vervangen door het "MAIL FROM" adres.
Dus behalve dat het niet 'mag', 'kan' het ook nog eens niet.

[Bosmonster]

TijnFLiP schreef op dinsdag 24 januari 2006 @ 22:34:
Je 'mag' geen gebruik maken van de return-path aangezien deze door de 'final delivery' SMTP server aan het mailtje moet worden toegevoegd. Zie:

http://www.ietf.org/rfc/rfc2821.txt

Wat je moet doen is de local part van de enveloped sender (dat is dus iets anders dan de FROM header!) per recipient aanpassen. De bounce wordt dan gestuurd naar dat adres. Aangezien elke recipient een eigen enveloped sender adres heeft kan je dus herkennen op welk adres de bounce optrad. Een mogelijkheid is bijv. dat je als enveloped sender (local part) de base64 representatie neemt van de recipient. Voorbeeld:

Je server heeft als domein example.com

Je stuurt een mailtje naar [e-mail]

Base64 van [e-mail] is dan:

cGlldEBqZXB1ay5ubA==

(de == moet je nog wel encoden naar bijv __) . Je stuurt dan het mailtje met als afzender

[e-mail]

Wanneer je nou een bounce krijg dan krijg je dat op dat adres binnen. Je kan daaruit weet het originele email adres verkrijgen door Base64 te decoden. Het voordeel is dat je geen state hoeft bij te houden. Het encoden met Base64 is maar een voorbeeld. Het kan op nog meer manieren.

Dus dan moet ik m'n hele server gaan reserveren voor inkomende email (alle adressen zijn mogelijk)... Dat gaat dus niet altijd. Ik wil dat bounces op 1 adres binnenkomen. Bovendien weet ik in bovenstaande situatie ook niet in welke context de mail is verstuurd (welke klant, mailing, etc).

[Creepy]

Bosmonster: dan pas je de codering aan Je kan er in kwijt wat je wilt, dus ook het ID van een mailing, ID van een klant, een timestap, etc. etc. etc.
VERP is DE techniek hiervoor en wordt door de meeste bulk e-mail tools hiervoor gebruikt. Als je niet een domein hiervoor kan reserveren (en dat is wat anders dan heel de server ) dan wordt het al een stuk moeilijker en zul je extra headers moeten gaan gebruiken om de juiste info in op te slaan. Er is alleen geen garantie dat je deze headers ook weer terugkrijgt in de bounce mail.

[xtra]

Bosmonster schreef op woensdag 25 januari 2006 @ 09:17:
[...]


Dus dan moet ik m'n hele server gaan reserveren voor inkomende email (alle adressen zijn mogelijk)... Dat gaat dus niet altijd. Ik wil dat bounces op 1 adres binnenkomen. Bovendien weet ik in bovenstaande situatie ook niet in welke context de mail is verstuurd (welke klant, mailing, etc).

Een catch-all adres op één domein is al genoeg. De context kun je vastleggen in je bounce-adres:
[e-mail] o.i.d.

[mjax]

Er is helaas geen eenduidige manier om de reden van een bounce vast te kunnen stellen. Ik ben al maanden bezig met een semi-geautomatiseerd systeem voor het verwerken van bounces en ik ben er achter dat er verschillende redenen kunnen zijn waarom je een "bounce" ontvangt:

* Echte bounce, user bestaat niet op maildomein
* Echte bounce, domein bestaat niet
* Mailbox vol
* Autoreply (bijvoorbeeld afwezigheidsassistent in Outlook)
* SPAM en/of virus filter
* Waarschuwing dat mail niet bezorgd kon worden (nog geen echte bounce)
* Too many redirects (wanneer een redirect uiteindelijk bij zichzelf uitkomt bijvoorbeeld)

Wanneer je zonder meer in al deze gevallen een emailadres als "niet bestaand" zou aanduiden, zou dat wel erg grof zijn. Daar komt bij dat de melding die je van de mailserver terugontvangt verschilt per type mailserver: er is geen eenduidige standaard voor het communiceren van dit soort meldingen.

Ook heb ik geprobeerd met allerlei extra X-headers meta data mee te geven die gebruikt kan worden bij het automatisch verwerken van een bounce. Dit werkt aardig als de mailserver het oorspronkelijke bericht ook mee terugstuurt. Dit doen ze lang niet allemaal.

Kortom, het is niet triviaal om bounces correct en betrouwbaar geautomatiseerd te verwerken. Wij houden het hier op een handmatig systeem dat ondersteund wordt met wat voorwerk van een slim PHP filter. Dit houdt in dat dat script de oorzaak van de bounce probeert te raden en noteert, maar dat handmatig de uiteindelijke beslissing wordt genomen.

[Bosmonster]

Ok interessant, maar welke header moet ik gebruiken voor die 'enveloped sender' dan? (als het niet de FROM is)

Heb lopen zoeken maar kon daar niet direct iets over vinden?

(of werkt het zo simpel niet?)

[ Voor 13% gewijzigd door Bosmonster op 25-01-2006 11:04 ]

[orf]

Ik laat mail naar [e-mail] pipen naar een PHP script. Dat is nogal wat efficienter dan een cron met imap open. Je script is daarnaast veel simpeler, omdat je de volledige mail (inclusief headers) in je script direct als variabele hebt.

De bovengenoemde 3 bounces als maatstaf gebruiken voor het op inactief zetten van een mailadres lijkt me een mooie oplossing.

Met een controlpanel is piping meestal zeer eenvoudig in te stellen; zonder controlpanel kun je het instellen op je mailserver. (http://www.evolt.org/article/Incoming_Mail_and_PHP/18/27914/)

[Creepy]

mjax: een "harde" bounce en een "softe bounce" (ala mailbox vol) zitten qua errorcode in een verschillende range (4xx tegen 5xx). Dus daar kan je ook wat meer informatie uithalen.

@Bosmonster: gewoon het return-path hiervoor gebruiken:

Uit de RFC die TijnFLip noemt
It is possible for the mailbox in the return path to be different
from the actual sender's mailbox, for example, if error responses are
to be delivered to a special error handling mailbox rather than to
the message sender. When mailing lists are involved, this
arrangement is common and useful as a means of directing errors to
the list maintainer rather than the message originator.

[mjax]

Creepy schreef op woensdag 25 januari 2006 @ 15:59:
mjax: een "harde" bounce en een "softe bounce" (ala mailbox vol) zitten qua errorcode in een verschillende range (4xx tegen 5xx). Dus daar kan je ook wat meer informatie uithalen.

Dat is de theorie ja, in de praktijk kom ik dagelijks bounces tegen zonder errorcodes.

Mijn bounceprocessor draait op een server die dagelijks ongeveer 1000 mailtjes verstuurd. Ik heb inmiddels een database met een heel oerwoud aan verschillende bounce responses opgebouwd, waarbij ik niet op een geautomatiseerde manier kan aangeven of het een hard of soft bounce is. De methodes die hierboven geschetst zijn helpen je om een heel eind te komen (95% of zo). Wat ik wil aangegeven met mijn bijdrage is dat door het ontbreken van een standaard op dit vlak, een betrouwbare geautomatiseerde bounceverwerking voor 100% niet mogelijk is.

[Creepy]

True, wij pakken het hier nog net ff wat anders aan. Alles waarvan we automatisch met volle 100% zekerheid kunnen zeggen dat het een hard bounce is, registreren we als een hard bounce, de rest als een soft bounce. Mocht een e-mail adres een x aantal keer soft bouncen, dan wordt dit adres alsnog verwijderd.

[Bosmonster]

Creepy schreef op woensdag 25 januari 2006 @ 15:59:
mjax: een "harde" bounce en een "softe bounce" (ala mailbox vol) zitten qua errorcode in een verschillende range (4xx tegen 5xx). Dus daar kan je ook wat meer informatie uithalen.

@Bosmonster: gewoon het return-path hiervoor gebruiken:


[...]

Er werd net verteld dat return-path daar niet voor bedoeld is. Daarom vroeg ik me af hoe je VERP in je headers kunt verwerken of dat je daar meer voor moet uithalen.

orf schreef op woensdag 25 januari 2006 @ 15:53:
Ik laat mail naar [e-mail] pipen naar een PHP script. Dat is nogal wat efficienter dan een cron met imap open. Je script is daarnaast veel simpeler, omdat je de volledige mail (inclusief headers) in je script direct als variabele hebt.

Ik lees in de beheeromgeving gewoon de bounce box uit, en parse per mail de X-header van het adres eruit. De gebruiker heeft dan direct de mogelijkheid het emailadres aan te passen (als het een duidelijke typ-fout is) of te verwijderen, of niks te doen. Aan de mailinhoud zelf kan die wel zien of het iets tijdelijks is of niet.

Dit werkt uiteraard alleen met kleinere mailings. Bij honderdern/duizenden bounces per mailing wil je dat niet met de hand doen

[ Voor 45% gewijzigd door Bosmonster op 25-01-2006 18:39 ]

[TromboneFreakus]

Creepy schreef op woensdag 25 januari 2006 @ 17:41:
True, wij pakken het hier nog net ff wat anders aan. Alles waarvan we automatisch met volle 100% zekerheid kunnen zeggen dat het een hard bounce is, registreren we als een hard bounce, de rest als een soft bounce. Mocht een e-mail adres een x aantal keer soft bouncen, dan wordt dit adres alsnog verwijderd.

En hoe stel je dat in de praktijk vast dan? Heb je wellicht een stukje PHP-code voorhanden die dit doet?

De opties die door verschillenden genoemd worden met allerlei flexibele mailadressen danwel domains gebruiken als afzender is niet haalbaar, simpelweg omdat er sprake is van een shared hosting account. Dus zo goed alles op het domain zelf instellen kan niet.

[mjax]

Creepy schreef op woensdag 25 januari 2006 @ 17:41:
Mocht een e-mail adres een x aantal keer soft bouncen, dan wordt dit adres alsnog verwijderd.

Dan zijn de verstuurde emails je niet al te waardevol. Ik heb bijvoorbeeld een aantal adressen in de lijst, die dagelijks softbouncen, omdat hun mailserver attachements uit de mails filtert. De email komt dus wel aan, maar zonder attachement. Om in zo'n geval na X soft-bounces te zeggen dat het adres dan maar geen email meer moet ontvangen, vind ik persoonlijk erg strikt. Uiteraard zou je een harde uitzondering voor dit type bounce kunnen inbouwen, maar dit is niet de enige variant.

Sterker nog, ik vraag me af welk doel het in dit geval dient om een dergelijk emailadres uit je verzendlijst te verwijderen. Is het doel zo weinig mogelijk mails te versturen, met het risico dat enkelen onterecht geen email meer ontvangen? Ik denk dat de zaken dan omgedraaid zijn, want volgens mij stuur je naar zo veel mogelijk mensen (die er om gevraagd hebben) een email, met het risico dat enkelen (soft)bouncen.

Kijk, het ligt natuurlijk ook aan de toepassing. Als het gaat om een verzendlijst voor spam/reclame emails, dan kun je wat grover filteren. Als je een notificatieservice runt (zoals wij dat doen), dan verwacht de eindgebruiker per email op de hoogte gehouden te worden.

Onze toepassing van een bouncefilter is om zo snel mogelijk te achterhalen welke emailadressen niet (meer) correct zijn, zodat we gebruikers (persoonlijk) kunnen benaderen om hun emailadres alsnog te verbeteren.

[Confusion]

Ik zou trouwens alle bounces wel even doublechecken als ik jou was. Het is zonde om een adres te verwijderen omdat iemand's persoonlijke mailserver er toevallig even uitligt.

[pietje63]

offtopic:
Bij iets als een studievereniging met 1500 leden denk ik nog dat het best wel te doen is om de bounces handmatig te verwerken, kost waarschijnlijk minder tijd. En hebben ze in Nijmegen niet ook allemaal een e-mail adres van de uni, kun je die niet gewoon gebruiken?

[Creepy]

mjax: onze klanten versturen (voornamelijk) e-mail nieuwsbrieven. Voor de spam-roepers: alles is opt-in Met het verwijderen van mensen uit het actieve bestand voorkomen we dat er mails worden verstuurd die toch niet aankomen (onze klanten betalen een heel klein bedrag per e-mail of sms).

Onze klanten kunnen zelf hun (hard)bouncelijst onderhouden (als ze dat willen).

Attachments ondersteunen we niet, dus van dat soort gesoftbounce hebben we geen last (en dat is ook 1 van de redenen waarom we attachments niet ondersteunen).

@TromboneFreakus: m.b.v. errorcodes + handmatig controleren wat verschillende mailservers terug kunnen geven en dat weer verwerken in de code (trail en error ja, maar onze applicatie is al wat jaartjes in ontwikkeling ). Daarnaast wordt elke verwerkte bounce e-mail gelogd, dus als er echt iets mis gaat dan zien we dat hier vanzelf. Ik heb geen voorbeeld voor je aangezien ik de code niet kan vrijgeven (daarnaast is het niet geschreven in PHP)

[ Voor 5% gewijzigd door Creepy op 26-01-2006 10:48 ]

[TromboneFreakus]

pietje63 schreef op donderdag 26 januari 2006 @ 10:11:

offtopic:
Bij iets als een studievereniging met 1500 leden denk ik nog dat het best wel te doen is om de bounces handmatig te verwerken, kost waarschijnlijk minder tijd. En hebben ze in Nijmegen niet ook allemaal een e-mail adres van de uni, kun je die niet gewoon gebruiken?

Die mailadressen staan niet in ons bestand en zijn ergens publiek beschikbaar om ze alsnog in te gaan voeren. Bovendien worden die adressen door maar weinig studenten actief gebruikt, je benadert ze veel beter op hun (bijv.) Homailadres

[TromboneFreakus]

Trouwens, als dan de mailheader niet aangepast mag worden, waarom doet dan zelfs het overbekende Tweakers.net (....) dit dan ook. Uit de meuktracker:

code:

From - Wed Jan 25 17:30:31 2006
Return-Path: <[e-mail]>
Subject: Tweakers.net software-update: Winamp 5.2 beta build 359
From: Tweakers.net Meuktracker <[e-mail]>

[pietje63]

TromboneFreakus schreef op donderdag 26 januari 2006 @ 14:30:
Trouwens, als dan de mailheader niet aangepast mag worden, waarom doet dan zelfs het overbekende Tweakers.net (....) dit dan ook. Uit de meuktracker:

code:

From - Wed Jan 25 17:30:31 2006
Return-Path: <[e-mail]>
Subject: Tweakers.net software-update: Winamp 5.2 beta build 359
From: Tweakers.net Meuktracker <[e-mail]>

pssst, klein geheimpje t.net is niet heilig.

Het aanpassen van de mailheader werkt volgens mij ook 'gewoon', maar als je het helemaal perfect wilt doen dan moet er geen gebruik van maken. Het leuke van dit P&W forum vind ik de discussies over het onderste uit de kan halen (zoals [rml][ php/html] php in html of html in php[/rml]) klinkt voor sommigen als mierengeneuk, maar velen vinden het interessant. Zo ook dit topic, ik gebruik momenteel ook 'gewoon' return-path' maar na zo'n topic ga ik er toch over nadenken...

[ Voor 24% gewijzigd door pietje63 op 26-01-2006 15:18 ]