[SMTP] rfc-ignorant.org DSN lijst vanwege weigeren lege afz.

[RetepV]

Hi. Ik merk net dat wij ongevraagd op de 'DSN list' van www.rfc-ignorant.com terecht gekomen zijn. Eén van onze klanten refusede een e-mail van ons met een verwijzing naar deze website.

Na tien keer overgelezen te hebben wat de reden zou zijn om op die lijst terecht te komen, snap ik het eindelijk. Onze mailserver accepteert geen e-mails zonder afzender-adres.

Volgens de heren (en/of dames) van rfc-ignorant.org is dat niet netjes tegenover andere postmasters. Die willen namelijk non-delivery reports kunnen sturen zonder daarin een afzender adres.

Maar onze mailserver ketst mails zonder afzender adres af als onderdeel van anti-spam en anti-relaying maatregelen. Is dat nou zo abnormaal? Ik vind het niet meer dan logisch dat ik alleen maar mails accepteer waarin een afzender staat.

Als mailserver gebruiken wij hMailServer (nadat Exchange voor de zoveelste keer gehacked was). Bij deze mailserver kan ik gewoon een vinkje zetten bij 'Allow empty sender address'. Maar geef mij eens één goede reden waarom ik dat zou doen (nee, dat ik dan van die DSN lijst af kom vind ik nog geen goede reden )?

Edit:

Het gaat hier dus om een live internet mailserver, niet om een thuisservertje ofzo. Als deze posting desondanks toch niet hier thuis hoort, gelieve hem dan te verplaatsen naar het juiste forum .

[ Voor 10% gewijzigd door RetepV op 22-08-2005 18:21 ]

[Verwijderd]

Heb even je titel aangepast, vind dit zelf wel een interessant punt eigenlijk.

[jochemd]

RetepV schreef op maandag 22 augustus 2005 @ 18:19:
Ik merk net dat wij ongevraagd op de 'DSN list' van www.rfc-ignorant.com terecht gekomen zijn.

Dat is niet ongevraagd. Misschien is het niet door jullie gevraagd, maar het is ook niet ongevraagd

Onze mailserver accepteert geen e-mails zonder afzender-adres.

Volgens de heren (en/of dames) van rfc-ignorant.org is dat niet netjes tegenover andere postmasters. Die willen namelijk non-delivery reports kunnen sturen zonder daarin een afzender adres.

Niet willen, moeten. Het is een verplichting om bij bepaalde soorten non-delivery notifications een null reverse path te gebruiken.

quote: ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt

One way
to prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a message
is transmitted the reverse-path MUST be set to null (see section
4.5.5 for additional discussion). A MAIL command with a null
reverse-path appears as follows:

MAIL FROM:<>

Maar onze mailserver ketst mails zonder afzender adres af als onderdeel van anti-spam en anti-relaying maatregelen. Is dat nou zo abnormaal?

Ja, dat is abnormaal. Er is een reden dat voor bepaalde berichten een null reverse-path verplicht is.

[Abom]

Tja, RFC's

Even een copy/paste uit de RFC die het null reverse-path verplicht:

If a server-SMTP has accepted the task of relaying the mail and later finds that the forward-path is incorrect or that the mail cannot be delivered for whatever reason, then it must construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path).

Hierdoor worden mailservers op spam-lijsten gezet. Nadat je eenmaal een mailtje geaccepteerd hebt, wordt je volgens veel anti-spam sites geacht het niet meer te NDR'en.

Verder staat er:

One way to prevent loops in error reporting...

M.a.w. één van de mogelijkheden zou kunnen zijn...

Persoonlijk vind ik het belangrijker om niet op spam-lijsten te komen dan op een site zoals rfc-ignorance.org. Ik vind interoperability ook belangrijk, maar het moet niet in het voordeel zijn van spammers of scammers.

Ik bedoel, het zal niet volgens de standaard uit 2001 zijn, maar in 2005 gaat er heel wat meer spam de wereld rond...altijd lekker voor spammers, geen afzender adres mee te hoeven sturen. Misschien moeten ze die RFC's eens herzien.

Maarja, ik bekijk het ook maar vanuit een praktisch oogpunt... moet zeggen dat ik niet goed genoeg in het wereldje zit om de volledige concequenties van dit 'issue' te overzien.

[ Voor 4% gewijzigd door Abom op 22-08-2005 21:06 ]

[jochemd]

Abom schreef op maandag 22 augustus 2005 @ 21:04:

Hierdoor worden mailservers op spam-lijsten gezet. Nadat je eenmaal een mailtje geaccepteerd hebt, wordt je volgens veel anti-spam sites geacht het niet meer te NDR'en.

Dan mag je het niet meer frivool NDR'en. Maar een NDR is niet per definitie frivool.
Bijvoorbeeld: een abonnee van XS4ALL levert een emailtje af bij de SMTP server van XS4ALL dat geadresseerd is aan [e-mail]. De SMTP server van XS4ALL probeert dat mailtje bij brakkeserver.invalid af te leveren. brakkeserver.invalid geeft vervolgens aan dat "me" geen geldig localpart is.Natuurlijk mag de SMTP server van XS4ALL dan nog een NDR versturen.

M.a.w. één van de mogelijkheden zou kunnen zijn...

Er zijn meerdere mogelijkheden en om de implementatie robuust te maken moeten ze allemaal toegepast worden zodat als er één faalt de andere alsnog de gevreesde loop kunnen voorkomen.

Persoonlijk vind ik het belangrijker om niet op spam-lijsten te komen dan op een site zoals rfc-ignorance.org.

Wat voor afzender-filtering pas je dan precies toe?

Ik bedoel, het zal niet volgens de standaard uit 2001 zijn, maar in 2005 gaat er heel wat meer spam de wereld rond...altijd lekker voor spammers, geen afzender adres mee te hoeven sturen.

Het is precies andersom. Als spam verstuurd zou worden met een null afzenderadres zou die ook niet gebounced worden want dan is er geen return address en dan wordt het rechtstreeks weggegooid. Dan werkt het standaard mechanisme om loops te voorkomen om spam uit de circulatie te houden.

Misschien moeten ze die RFC's eens herzien.

Ze? Er is geen ze. Er is alleen een wij. Als die RFC je niet bevalt dan moet je je op de juiste IETF mailinglist abonneren en vertellen wat er mis mee is en hoe het beter kan. (Been there, done that, en als je een goed verhaal hebt dan luisteren ze echt wel.)

[RetepV]

jochemd schreef op maandag 22 augustus 2005 @ 21:50:
[...]
Het is precies andersom. Als spam verstuurd zou worden met een null afzenderadres zou die ook niet gebounced worden want dan is er geen return address en dan wordt het rechtstreeks weggegooid. Dan werkt het standaard mechanisme om loops te voorkomen om spam uit de circulatie te houden.

Dat is dus maar helemaal de vraag. Spam kan wel verstuurd worden met een NULL afzenderadres, maar met een ingevuld REPLY-TO adres. Ik zou verwachten dat de mailserver in dat geval een NDR terugstuurt naar het REPLY-TO adres. Dat veld is namelijk bedoeld om replies naartoe te sturen. In dat geval heb je dus een mail met een NULL afzenderadres, waar toch een NDR uit voortkomt.

En op deze manier loops voorkomen is eigenlijk wel heel erg krukkig. Tenslotte laat elke mailrelay een 'Received: FROM' veld achter. Een dergelijk mechanisme bedenken om loops te voorkomen is vele malen effectiever. Mails met een NULL afzenderadres kun je dan opeten, zodat spammers er geen gebruik van kunnen maken, en loops zijn dan ook te voorkomen.

Ik snap dat loops heel ernstig zijn. Maar wat ik niet snap is waarom dat wordt geprobeerd op te lossen door gebruik te maken van een halfslachtige workaround. Waarom niet een fatsoenlijk mechanisme inbouwen om loops te voorkomen?

Kijk, wat gebeurt er nu...? Een heleboel servers maken geen gebruik van blacklists om spam op te eten, die relayen spam gewoon lekker door. Door deze workaround worden deze servers niet verplicht om zich aan te sluiten bij blacklists. Aan de ene kant wordt nu het verkeer beperkt door loops tegen te gaan, maar aan de andere kant wordt het verkeer weer vergroot omdat mensen er mee weg komen om geen anti-spam maatregelen te nemen. Dat is toch dweilen met de kraan open?

Overigens stuurt onze server geen NDR's. De laatste keer dat ik dat aan had gezet was het spamverkeer in 2 weken tijd verdriedubbeld.

Edit:

Ik schreef in mijn eerste posting "Maar onze mailserver ketst mails zonder afzender adres af als onderdeel van anti-spam en anti-relaying maatregelen.". Maar ik bedoelde met 'afketsen' eigenlijk 'opeten', aangezien onze mailserver dus geen NDR's genereert. Klanten die een verkeerd e-mail adres gebruiken hebben gewoon pech gehad. Als ze geluk hebben, dan genereert de afleverende mailserver een NDR aan de hand van de foutmelding die hij terugkrijgt als hij de mail probeert af te leveren op onze server.

[ Voor 16% gewijzigd door RetepV op 31-08-2005 10:36 ]

[jochemd]

RetepV schreef op woensdag 31 augustus 2005 @ 10:32:

Dat is dus maar helemaal de vraag. Spam kan wel verstuurd worden met een NULL afzenderadres, maar met een ingevuld REPLY-TO adres. Ik zou verwachten dat de mailserver in dat geval een NDR terugstuurt naar het REPLY-TO adres. Dat veld is namelijk bedoeld om replies naartoe te sturen. In dat geval heb je dus een mail met een NULL afzenderadres, waar toch een NDR uit voortkomt.

NDRs sturen naar een niet verplicht emailadres waarvan je pas in de DATA fase kan zien of het bestaat? Dan is je implementatie behoorlijk debiel. Om nog maar even te citeren:

quote: ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt

Implementors of automated email processors should be careful to make
sure that the various kinds of messages with null reverse-path are
handled correctly, in particular such systems SHOULD NOT reply to
messages with null reverse-path.

En op deze manier loops voorkomen is eigenlijk wel heel erg krukkig. Tenslotte laat elke mailrelay een 'Received: FROM' veld achter.

Alleen SMTP relays doen dat en SMTP is niet het enige protocol. Ook gateways naar SMS, UUCP etc. etc. moeten gefaciliteerd worden.

Ik snap dat loops heel ernstig zijn. Maar wat ik niet snap is waarom dat wordt geprobeerd op te lossen door gebruik te maken van een halfslachtige workaround. Waarom niet een fatsoenlijk mechanisme inbouwen om loops te voorkomen?

Omdat niemand een beter mechanisme kan bedenken. En als je denkt dat jij dat wel kan dan zou ik je adviseren om je geweldige nieuwe protocol op de relevante mailinglists te publiceren.

Kijk, wat gebeurt er nu...? Een heleboel servers maken geen gebruik van blacklists om spam op te eten, die relayen spam gewoon lekker door. Door deze workaround worden deze servers niet verplicht om zich aan te sluiten bij blacklists.

Begrijp ik het goed dat jij mensen wil verplichten om zich aan te sluiten bij blacklists? Zodat iemand anders, de beheerder van de blacklist, de controle krijgt over welke email er aankomt of niet?

Ik schreef in mijn eerste posting "Maar onze mailserver ketst mails zonder afzender adres af als onderdeel van anti-spam en anti-relaying maatregelen.". Maar ik bedoelde met 'afketsen' eigenlijk 'opeten', aangezien onze mailserver dus geen NDR's genereert.

Als email echt wordt aangenomen (250 OK) en vervolgens wordt gedelete is daar technisch niets mis mee. Wat de vraag oplevert waarom je precies op die lijst staat. Misschien is het handig om eens te vertellen om welke domeinen het gaat.

[igmar]

RetepV schreef op maandag 22 augustus 2005 @ 18:19:
Na tien keer overgelezen te hebben wat de reden zou zijn om op die lijst terecht te komen, snap ik het eindelijk. Onze mailserver accepteert geen e-mails zonder afzender-adres.

Dan kom je inderdaad op RFC ignorant terecht ja.

Maar onze mailserver ketst mails zonder afzender adres af als onderdeel van anti-spam en anti-relaying maatregelen. Is dat nou zo abnormaal?

Behoorlijk, aangezien je d'r niks mee opschiet. Ik kan in from: <*> zo ongeveer elk adres invullen wat ik wil. Het sturen van een postmaster replay met <> als afzender gaat het heen en weer stuiteren van mails tegen, aangezien de meeste slechte MTA software (en da's helaas zowat alles op het Windows platform) ook nog de gehele body meestuurt.

Ik vind het niet meer dan logisch dat ik alleen maar mails accepteer waarin een afzender staat.

Spammers gebruiken tegenwoordig gewoon random namen en random domeinen, en allang geen <> meer.

Als mailserver gebruiken wij hMailServer (nadat Exchange voor de zoveelste keer gehacked was). Bij deze mailserver kan ik gewoon een vinkje zetten bij 'Allow empty sender address'. Maar geef mij eens één goede reden waarom ik dat zou doen (nee, dat ik dan van die DSN lijst af kom vind ik nog geen goede reden )?

Omdat het een legitiem gebruik heeft, en je d'r geen spam ed mee tegenhoud ?

[ Voor 3% gewijzigd door igmar op 31-08-2005 11:54 ]