Onderwerp: Het hanteren van de RFC's op je mailservers

Oorspronkelijk geplaatst door Mikey

zoals je zelf al aangeeft als de versturende partij in hun maillog terug kan vinden wat er fout gaat vind ik dat je een prima en nette oplossing aan gedragen hebt .

Vaak krijgt de verstuurder ook nog een error als er op SMTP niveau iets verkeerd ging.

@ Hans, slechte vergelijking imho. Een hoekje van een stukje briefgeld af is heel wat anders dan dit.

Maar ik heb wel eens meegemaakt dat een biljet werd geweigerd omdat het in een slechte staat was.

Wat dachten jullie van het beste van twee werelden?

Wij filteren de correcte e-mails van de niet correcte e-mails, de correcte e-mails komen netjes aan in de inbox, de overige e-mails worden afgeleverd in de junkmail folder. Tevens krijgt de afzender netjes een NDR zodat ze weten dat hun e-mail niet goed is afgeleverd. Klanten waarvan e-mail consequent in de junkmail folder komt zetten we op de whitelist, zodat deze geen problemen meer hebben.

RFC én flexibel

Oorspronkelijk geplaatst door Mikey

zoals je zelf al aangeeft als de versturende partij in hun maillog terug kan vinden wat er fout gaat vind ik dat je een prima en nette oplossing aan gedragen hebt .

<spottend lachje>
Degene die weten waar ze dat moeten zoeken hebben het toch wel voor elkaar.
</spottend lachje>

Oorspronkelijk geplaatst door MediaServe

Wat dachten jullie van het beste van twee werelden?

Wij filteren de correcte e-mails van de niet correcte e-mails, de correcte e-mails komen netjes aan in de inbox, de overige e-mails worden afgeleverd in de junkmail folder. Tevens krijgt de afzender netjes een NDR zodat ze weten dat hun e-mail niet goed is afgeleverd. Klanten waarvan e-mail consequent in de junkmail folder komt zetten we op de whitelist, zodat deze geen problemen meer hebben.

RFC én flexibel

Daar zou ik tenminste klant willen worden... ow dat ben ik ook ooit geweest..

Oorspronkelijk geplaatst door crazycoder

<spottend lachje>
Degene die weten waar ze dat moeten zoeken hebben het toch wel voor elkaar.
</spottend lachje>

Ook ik moet na bovenstaand even goed glimlachen

Oorspronkelijk geplaatst door MediaServe

Wat dachten jullie van het beste van twee werelden?

Wij filteren de correcte e-mails van de niet correcte e-mails, de correcte e-mails komen netjes aan in de inbox, de overige e-mails worden afgeleverd in de junkmail folder. Tevens krijgt de afzender netjes een NDR zodat ze weten dat hun e-mail niet goed is afgeleverd. Klanten waarvan e-mail consequent in de junkmail folder komt zetten we op de whitelist, zodat deze geen problemen meer hebben.

RFC én flexibel

Mooie oplossing, ben ik met je eens.

Al vraag ik me af met welke software je dat voor elkaar gekregen hebt, daar zit wat custom werk in gok ik zo?

Oorspronkelijk geplaatst door Wido

Vaak krijgt de verstuurder ook nog een error als er op SMTP niveau iets verkeerd ging.

@ Hans, slechte vergelijking imho. Een hoekje van een stukje briefgeld af is heel wat anders dan dit.

Maar ik heb wel eens meegemaakt dat een biljet werd geweigerd omdat het in een slechte staat was.

Als het inderdaad in heel slechte staat is, dan kan iedereen begrijpen dat 't geweigerd wordt. Zie het als een mailtje zonder afzender of iets dergelijks. Maar als het briefje niet helemaal okay is, maar eigenlijk overal geaccepteerd wordt, dan is het niet goed voor de klandizie om zo'n briefje te weigeren.

Begrijp me niet verkeerd: ik vind 't op zich een net initiatief, maar ik ga me er echt niet aan branden om die mails te weigeren.

Wat MediaServe voorstelt is wel leuk, maar komt niet in de buurt van wat Wido nu heeft geconfigureerd.

Oorspronkelijk geplaatst door Wido

Mooie oplossing, ben ik met je eens.

Al vraag ik me af met welke software je dat voor elkaar gekregen hebt, daar zit wat custom werk in gok ik zo?

Het eerste deel is makkelijk. Zoals ook al gemeld in http://www.webhostingtalk.nl/851046-post28.html zorgen we ervoor dat foute RFC hosts extra punten krijgen in de spam filtering. Stel dit filter zo hoog dat het altijd in de spam zal komen en het staat in je junk folder.
Dit is standaard te doen met spamassassin en spamd.

X-Spam-Report:
* 0.1 FORGED_RCVD_HELO Received: contains a forged HELO

Voor spamassassin kun je indien een bepaalde filter 'afgaat' instellen dat er een custom aktie uitgevoerd wordt. In deze actie zul je dus moeten zorgen dat er een ND mail terug verzonden wordt. Hier zal wel een klein stukje custom bij komen.

Kan je dat ook instellen als spamassassin draait via amavisd-new?

Ik wilden namelijk eerst de optie SPF optioneel maken per bij het CP maar het voorbeeld dat ik had gevonden verwierp de email gewoon

Dus wou wil het laten markeren spam en heb daar voor zelfs het quarantaine systeem van amavisd-new ontleed, zodat deze buiten dat werd opgeslagen als spam.

Oorspronkelijk geplaatst door Wido

Mooie oplossing, ben ik met je eens.

Al vraag ik me af met welke software je dat voor elkaar gekregen hebt, daar zit wat custom werk in gok ik zo?

Met Microsoft Exchange kun je spam zowel bouncen als afleveren en ook afleveren in alternatieve folders. De regels die jij beschreef, zoals controleren op de HELO en reverse DNS zitten in de meeste spamfilters. Dus het kan vrij eenvoudig ingesteld worden. Wij gebruiken hier voor eigen gebruik GFI MailEssentials voor, maar dit pakket is (naar mijn mening) helaas te duur om voor klanten in te zetten.

Verbeter me als ik je verkeerd interpreteer.

Oorspronkelijk geplaatst door Rollerscapes

Of ik er wat tegen heb? Totaal niet
Ik vind het juist dat het gebeurd! Die standaards zijn er niet voor niets.

Ik heb mijn mail server zo ingesteld dat hij een EHLO nodig heeft anders weigert hij gewoon en dat de mail moet RFC geldig zijn.

Jij vereist een EHLO en weigert een HELO? Indien ja, dan overtreed je je eigen regel, want een oude server (of client) zal een HELO sturen i.p.v een EHLO en de server moet hier op terug vallen. Zie RFC 2821:

Contemporary SMTP implementations MUST support the basic extension
mechanisms. For instance, servers MUST support the EHLO command even
if they do not implement any specific extensions and clients SHOULD
preferentially utilize EHLO rather than HELO. (However, for
compatibility with older conforming implementations, SMTP clients and
servers MUST support the original HELO mechanisms as a fallback.)

Helo EHLO, ik haal die twee altijd door de war

Ik heb het even een aantal dagen gedraait op een van onze mailserver waaruit blijkt dat het niet helemaal succesvol is, alhoewel, te succesvol, daarom gaan we het maar niet doen of iig gefaseerd.

[code]
[root@** log]# cat /var/log/maillog |grep 'Helo command rejected' |wc -l
6287
[root@** log]#

En nog wat .local's waar bijv. Exchange nog wel eens gebruik van wil maken, gaat erg de mist in.

Oorspronkelijk geplaatst door Wido

Oh, ja shit :P

Ik wilde zelf nog verder gaan door te controleren of je rDNS wel met je HELO overeen komt, echter gaat dat denk ik té ver.

Het is toch van de zotte dat zo veel mensen brak geconfigureerde mailservers hebben en dat jij er de dupe van bent als je je aan de regels houdt?

Gelukkig vallen de klachten bij ons nog mee en ik verwacht ook dat het zo blijft.

America Online (AOL) doet dit.

Maar wat als je een school als klant hebt, welke hun mailserver niet goed heeft ingesteld met rDNS entries en hun service provider (Kennis ADSL) doet moeilijk over het instellen van rDNS entries (ze weigeren dit te doen). Of gebeurt dit nergens? Je zult hun in ieder geval moeten helpen met het aanpassen van hun configuratie.

Oorspronkelijk geplaatst door Glenn

En waarschijnlijk zal het inderdaad nooit opgelost worden. Hoevaak ik geen boze klanten aan de mail/lijn heb gehad wanneer ik onze mailserver weer strenger maakte. Op een gegeven moment was het zo erg (dreigen met contract opzeggen) dat we de mailserver losser hebben gemaakt.

Helaas maar waar.

Ik denk er ook zo over hoor. Veel bedrijven draaien zelf Exchange-servers. Je kunt geen mail vanaf deze servers gaan weigeren vanwege het feit dat ze niet volgens RFC werken in mijn ogen.

Oorspronkelijk geplaatst door phreak

En nog wat .local's waar bijv. Exchange nog wel eens gebruik van wil maken, gaat erg de mist in.

Nee. De stommeling die z'n spulletje niet goed heeft geconfigureerd.

Wij accepteren .local niet als afzender..