Zo'n vacation / out of office plugin voorziet uiteraard ook in het doorsturen van de mail zonder de afzender te mailen.
Dan is het geen out-of-office
reply meer, maar een out-of-office
forward...
Automatisch genereerde mail komt vaak van een 'noreply@' of een ander niet-bestaand adres. Dat levert een bounce op maar op een bounce wordt in de regel niet gereplied omdat de headers gecontroleerd worden.
Dat is theorie. Bounces kan je op verschillende niveaus krijgen afhankelijk van de configuratie bij de remote mailserver. Je kan daarvoor een als 'oplossing' een niet-bestaande afzender geven aan de out-of-office reply. Dat is geen elegante oplossing imo.
Die oneindige loop is uiteraard onzin, een fatsoenlijke responder houdt bij aan wie ie mail heeft verzonden.
Ook dat is theorie. Wat nou als de remote out-of-office reply mailserver je een volledig 'nieuwe' mail stuurt? Zonder de In-reply-to header. Vertrouw nooit andere mailservers zomaar.
Het ging mij alleen om de mogelijkheid om een bestaande responder te gebruiken. Configuratie van dat ding is uiteraard in handen van de sysadmin van die doos en staat dus los van de mail client functionaliteit.
Dus waarom wil je het dan wel in webmail client functionaliteit?
In een zakelijke(re) omgeving is het vaak een eis om out of office reply in te stellen. En iets als: "tijdens mijn vakantie wordt de e-mail niet doorgestuurd naar een collega, als het dringend is neem dan contact op met X of bel Y" is niet ongebruikelijk.
Dat bedenken mensen die geen betere oplossingen kunnen bedenken. Maffe managers of iets dergelijks.
Ik moet er niet denken als ik klakkeloos alle mail van een collega krijg tijdens zijn/haar vakantie. Dat is pas een ramp

Dat hoeft ook neit zo klakkeloos. Daarvoor zijn dingen als shared folders en functionele aliassen voor uitgevonden.
En eventueel andere systemen met mail als middel. Denk aan ticketing systemen, mailinglists, groupware oplossingen, etc.
Praktijk is gewoon dat out-of-office replies meer narigheid bezorgen dan waar je op het eerste moment aan zou denken.
[Reactie gewijzigd door gertvdijk op maandag 7 september 2009 21:51]
Ook dat is theorie. Wat nou als de remote out-of-office reply mailserver je een volledig 'nieuwe' mail stuurt? Zonder de In-reply-to header. Vertrouw nooit andere mailservers zomaar.
Er wordt niet alleen maar gekeken naar zo'n In-reply-to header, ook andere X headers kunnen gebruikt worden.
Een autoresponder kijkt gewoon naar from en to adres. Als ie die kent verstuurt ie hem niet nog een keer tenzij de resent tijd (1 week default) verstreken is.
Zo replied ie ook niet op spam mail als de header X-Spam-* bevat. Desondanks blijft het gewoon een stuk software, dus er zal allicht wel een keer iets geautoreplied worden wat niet de bedoeling is.
Dan is het geen out-of-office reply meer, maar een out-of-office forward...
En die kan je niet met elkaar combineren omdat ....?
Dus waarom wil je het dan wel in webmail client functionaliteit?
Het enige wat je wil in je mailclient is de mogelijkheid tot het instellen van een out of office reply. Dat het via /usr/bin/vacation wordt aangeroepen vanuit .forward of dat via een Postfix transport naar vacation.pl gaat maakt geen bal uit.
Je moet niet een andere app gebruiken om dat in te stellen.
Dat bedenken mensen die geen betere oplossingen kunnen bedenken. Maffe managers of iets dergelijks.
Ik merk dat klanten en collega's het waarderen dat ze een out of office reply krijgen i.pv. geen reactie. Die hebben echt geen boodschap aan die anti-spam argumenten van je.
Dat hoeft ook neit zo klakkeloos. Daarvoor zijn dingen als shared folders en functionele aliassen voor uitgevonden.
En eventueel andere systemen met mail als middel. Denk aan ticketing systemen, mailinglists, groupware oplossingen, etc.
Dat is allemaal leuk, maar feit blijft dat je ook persoonlijke mail krijgt die alleen voor jou interessant is i.v.m. jouw functie of kennis. Of misschien wil de afzender wel alleen dat ik het te lezen krijg i.p.v. de hele organisatie.