Bekijk Volledige Versie : Het hanteren van de RFC's op je mailservers
Hallo,
Sinds 2 weken hebben wij ons mailcluster nu strenger afgestelt, zo eisen we nu:
- Een FDQN HELO waarvoor een A-record is.
- Een geldige rDNS
Dit is gefaseerd ingevoerd, eerst de FDQN HELO en 2 weken later de geldige rDNS.
Nu geeft vooral het laatste problemen.
Voor externe partijen heb ik netjes een Wiki pagina gemaakt: https://support.pcextreme.nl/wiki/index.php/Aflevering_e-mail_bij_PCextreme_BV
Nu krijgen we aardig wat meldingen van klanten die zeggen sommige mail niet te ontvangen, maar zodra je vertelt over hoe en wat ben je ineens de boeman.
Ik vergelijk het met een voetbal wedstrijd. Daar zijn ook regels waar je je aan te houden hebt. Je kan best voetballen waar je elkaar de schenen kapot schopt, dat is immers ook voetbal. Maar je kan het ook spelen volgens de regels.
Echter begrijpen veel mensen dit nog niet.
Ik ben echter niet van plan om het beleid terug te draaien, regels zijn er niet voor niets. Én je houd een berg spam tegen. Onze spamratio is van 90% naar 60% terug gezakt, dat is nogal wat.
Nu wil ik met deze thread twee dingen bereiken:
- Jullie mening hier over
- Mensen leren hoe het wel moet, hoe je je server dus moet configureren.
Ik gebruik in mijn Postfix overigens:
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_hostname
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_client
Ik wil zelf nog verder gaan door ook nog toe
Graag jullie reacties.
opzich, als iedereen zich aan de regels zou gaan houden is het in no-time allemaal een stuk leuker en netter op internet enzo. Ik heb zelf de default exim4-spamblocker DA configuratie en om eerlijk te zijn weet ik niet of die ook helo required heeft... Zou ik even moeten nakijken :)
De regels zijn er om je aan te houden :)
Deze procedure hanteerden wij (nog) niet, ik ga dit ook eens implementeren op onze mailservers, even aankijken hoe dat het werkt voor ons.
strict_rfc821_envelopes = yes
^^ die doet het ook erg goed. Ik heb afgelopen tijd er hoop ruzie om gehad en de boodschap vanuit mijn kant is gewoon heel duidelijk, sla de rfc er maar op na jullie configuratie deugt niet.
AlexanderOnline
04/05/07, 20:32
Intressant dat dit ook zoveel spam tegenhoud. Alleen heb je een idee hoeveel % daarvan toch goed bedoeld is? Ik vind het wel een goede aanpak om zo een wiki op te zetten om klanten te informeren, zodat je hier naar kan verwijzen. Alleen als het teveel goed bedoelde mail tegenhoud moet je overwegen of je dit wel in moet voeren, klanten denken nu eenmaal simpel en raklen dan ontevreden...
De spamratio zakt heel erg, maar je legitieme berichten niet.
De grote partijen hebben hun instellingen allemaal naar de RFC's, het zijn vooral de kleine partijen met 1 of 2 servers die zich niet aan de regels houden.
De klachten vallen nog mee, op ons klantenbestand zijn er in 2 weken nu denk ik 10 tot 15 klachten gekomen.
De spam komt vooral van gehackte thuis PC's die nooit aan de RFC's voldoen, daardoor houd je veel spam buiten de deur.
crazycoder
04/05/07, 23:31
De spamratio zakt heel erg, maar je legitieme berichten niet.
De grote partijen hebben hun instellingen allemaal naar de RFC's, het zijn vooral de kleine partijen met 1 of 2 servers die zich niet aan de regels houden.
De klachten vallen nog mee, op ons klantenbestand zijn er in 2 weken nu denk ik 10 tot 15 klachten gekomen.
Dat is mooi voor jullie. Wij hadden het 3 dagen draaien en kregen de ene klacht na de andere, toen waren er nog maar 50 gebruikers die daar stonden... O.a. business dsl lijnen van kpn zijn niet correct geconfigureerd. Omroep clubs, andere zakelijke relaties die het gewoon niet voor elkaar hebben.
Scholen: zelfde laken een pak.
DNS is tegenwoordig naar het schijnt iets waar iedere l*l de behanger zich mee bezig kan houden en dan ook nog verwacht dat het werkt.
Als je de beheerders e.e.a. uit ga proberen te leggen dan stuit je op een muur van onwil en onbegrip.
Alhoewel ik het in beginsel een prima methode vind om spam te stoppen kunnen wij het in de zakelijke markt (nog) niet doorvoeren. Helaas.. mag ik wel zeggen..
Ik snap nog steeds niet waarom menig beheerder van servers zich niet eerst verdiept in de benodigde RFC's (en dus regels) van bepaalde protocollen of diensten.
Het is een kleine moeite om je server goed af te stellen.
Maar ja, het is leuk he dat als je klant een reverse lookup doet op je ip en hij ziet staan hosted.by.ISP2034535i2oqoewqq.ergens.
Vervolgens draai je op de zelfde machine je mail daemon en je voldoet niet meer aan de RFC's.
Ik denk dat menig zolderkamer hoster (dat zijn die met 1 of 2 servers die men bedoelt) niet eens weet wat een RFC is. Als ze ze weten te vinden dan klagen ze dat het te technisch engels is.
Jamer genoeg stuit je bij het afdwingen van dat soort regels op een hoop onbegrip bij je klanten. Zeker als iets voorheen wel werkte, en nu niet meer omdat jij je aan de regels wilt houden.
Waarom maken we geen FAQ om een goed functionerende e-mailserver op te zetten? Daarbij rekening houden met de verschillende CP's als Cpanel, Plesk, HELM IW, DA en de MTA's.
Daar wil ik ook graag aan meewerken, en eventueel het domein configureren.nl er voor gebruiken?
Mochten er meerdere mensen interesse hebben, dan kunnen we dat zeker gezamelijk doen?
Ik wil zelf nog verder gaan door ook nog toe
Je wilde hier nog iets typen?
Je wilde hier nog iets typen?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.
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.
Weet je wat ik mij afvraag: Is het wel haalbaar.
Veel bedrijven hebben een eigen (Exchange)-server welke gebruikt maakt van hun internetverbinding. De provider zou dan zo vriendelijk moeten zijn de juiste rDNS in te stellen en dat gaat nooit gebeuren...
Weet je wat ik mij afvraag: Is het wel haalbaar.
Veel bedrijven hebben een eigen (Exchange)-server welke gebruikt maakt van hun internetverbinding. De provider zou dan zo vriendelijk moeten zijn de juiste rDNS in te stellen en dat gaat nooit gebeuren...Correct en daar liep ik dan ook tegenaan.
Om die reden houdt ik het hier bij.
Neemt niet weg dát als je het kan instellen, dat je het ook moet doen! (ik bedoel dus die rDNS voor je server e.d.)
Correct en daar liep ik dan ook tegenaan.
Om die reden houdt ik het hier bij.
Neemt niet weg dát als je het kan instellen, dat je het ook moet doen! (ik bedoel dus die rDNS voor je server e.d.)
Weet je wat de oplossing is? Elke provider moet de uitgaande e-mail poort blokeren en alles door hun e-mailservers laten gaan welke wel rDNS hebben ;)
Weet je wat de oplossing is? Elke provider moet de uitgaande e-mail poort blokeren en alles door hun e-mailservers laten gaan welke wel rDNS hebben ;)Zou een oplossing zijn, maar dat wil niet iedereen.
Bij een business lijn kan ik het opzich snappen.
Wij krijgen op kantoor binnenkort een glasvezel lijn, ik mail toch echt liever via mijn eigen servers dan via die van mijn provider.
Ik moet zeggen dat ik een groot voorstander ben van het eisen van een juiste rDNS en een correcte HELO(/EHLO), ook strict_rfc821_envelopes = yes is een hele fijne setting waar niemand een probleem mee zou mogen hebben.
Daarnaast is ook reject_unknown_sender_domain bij de smtpd_sender_restrictions een logische setting. Als het domein van de afzender niet bestaat, dan is er ook geen reden om mail van ze aan te nemen.
De rDNS van een mailserver hoort gewoon altijd te kloppen met de forward DNS. Dat de HELO niet altijd overeen komt, dat kan. Om daar op te blocken gaat mij nu nog te ver, eventueel wel een paar tienden extra punten in spamassassin.
Dat access providers poort 25 blokkeren, kan ik me wel wat bij voorstellen, het heeft voor en nadelen. Zolang je maar wel gewoon via de alternatieve mail submission port kan versturen, met gebruik van authenticatie, kan ik access providers eigenlijk alleen maar gelijk geven dat ze 25 blocken, zeker dus OOK met zakelijke verbindingen. Draai je op kantoor een eigen mailserver? Dan gebruikt die maar fijn de relay van de provider.
Als alle grote access providers eenmaal poort 25 blocken, dan kan je dus ook wel degelijk gaan vereisen dan de HELO hostnaam gelijk is aan de DNS hostnaam, maar tot die tijd is dat geen optie.
crazycoder
05/05/07, 13:13
Als alle grote access providers eenmaal poort 25 blocken, dan kan je dus ook wel degelijk gaan vereisen dan de HELO hostnaam gelijk is aan de DNS hostnaam, maar tot die tijd is dat geen optie.
Als je klanten alleen e-mail uit Nederland krijgen heb je gelijk.
Soms is het jammer dat internet niet aan de grenzen stopt :)
Wij krijgen trouwens ook via de smtp servers van grote providers zoals orange voldoende spam binnen. Met orange als uitschieter.
Veel bedrijven hebben een eigen (Exchange)-server welke gebruikt maakt van hun internetverbinding. De provider zou dan zo vriendelijk moeten zijn de juiste rDNS in te stellen en dat gaat nooit gebeuren...
Deze mensen moeten de SMTP-server van hun provider dan instellen als smart-host. Je exchange-server stuurt dan de mail die niet lokaal bezorgt kan worden naar de SMTP-server van je provider... probleem opgelost!
Deze mensen moeten de SMTP-server van hun provider dan instellen als smart-host. Je exchange-server stuurt dan de mail die niet lokaal bezorgt kan worden naar de SMTP-server van je provider... probleem opgelost!
Bij sommige providers blijft de mail wel eens hangen, als je dan de headers ziet loopt het bij de provider een 15 minuten tot 2 dagen (!!) vertraging op. Daar elke mail hop die er tussen uit kan graag. Zeker als die systemen beheerd worden door andere. Dan liever rechtstreeks vanuit mail systeem, naar het (MX) systeem waar het terecht hoor te komen.
Ik ken providers die houden voor mail-relay gewoon een delay aan van minstens 6 uur.
Dat houd in als je server via hun server moet relayen, dan zal elk mailtje een vertraging oplopen van 6 uur.
Daar ben je niet blij mee, elke hop die er tussen uit kan zou je er tussenuit moeten halen.
Het belangrijkste zou zijn als de grotere providers mee zouden gaan doen op het controleren van RFC's. HIermee zouden ze vervolgens ook veel spam van hun eigen klanten uit (botnets) kunnen voorkomen.
Werkt prima, veel minder spam op mijn account :)
En uiteraard ben ik het helemaal eens met dat mensen zich aan de regels moeten houden, en niet moeten zeuren
Ik vraag me dan alleen af, is het meerendeel van de mensen nu "bang" om hun servers strenger te maken?
Want op die manier schieten we natuurlijk niets op.
Ik vraag me dan alleen af, is het meerendeel van de mensen nu "bang" om hun servers strenger te maken?
Want op die manier schieten we natuurlijk niets op.
Niet bang, maar uiteindelijk hebben de klanten het toch voor het zeggen. Ik heb er niets aan dat klanten weg gaan omdat wij persee onze mailserver aan de regels willen laten afdwingen. De klant wil gewoon zijn mail. En dat de verzendende partij zijn zaakjes niet op orde heeft maakt onze klant niet uit.
De klant heeft wel al gekozen dat wij uitgaand wel op orde hebben, zodat wat voor instellingen de andere kant heeft, dat zijn mail bij versturen gewoon verzonden wordt, maar ondertussen wil die wel alle mail van brakke verzendende partijen..
Dan liever 1 a 2 spam berichten tussen zijn mail, dan mail missen. Want de rest wordt wel opgevangen voor de spamfilters. Al hebben die dus nu meer te doen. Maar de extra resources betalen de klant uiteindelijk voor.
Ja, maar op die manier wordt het probleem dus nooit opgelost.
Omdat er servers losjes blijven afgestelt ziet niemand de noodzaak zijn systeem netjes te configureren.
Mijn mail komt toch aan? Waarom zou ik dan wat gaan leren over SMTP?
Ja, maar op die manier wordt het probleem dus nooit opgelost.
Omdat er servers losjes blijven afgestelt ziet niemand de noodzaak zijn systeem netjes te configureren.
Mijn mail komt toch aan? Waarom zou ik dan wat gaan leren over SMTP?
Technisch gezien heb je gelijk.
Echter merk je zoals je aangeeft dat er toch mails zijn die nu niet meer aankomen. Als dienstverlener moet elke ISP zelf kiezen tussen:
- strak de RFC volgen en een nadelige zakelijke performance ondervinden
- vrij omgaan met de richtlijnen en zo flexibeler zijn
De spam die je door deze maatregel filter, had je die niet op een andere manier toch al gefilterd? Weegt het niet ontvangen van legitieme mails op tegen het voordeel van minder spam ontvangen?
Ja, maar op die manier wordt het probleem dus nooit opgelost.
Omdat er servers losjes blijven afgestelt ziet niemand de noodzaak zijn systeem netjes te configureren.
Mijn mail komt toch aan? Waarom zou ik dan wat gaan leren over SMTP?
Ja en nee.
Wij zullen dus zelf wel volgens de RFC's werken, echter dwingen we niet af dat andere dat ook moeten doen. Wij zullen dus geen mail weigeren omdat andere zich niet aan de RFC's houden.
Echter zal het spamfilter wel weer punten toekennen als de verzendende partij zich niet aan de RFC's houden. Uiteindelijk krijgt onze klant dus wel zijn mail, alleen gemarkeerd als spam.
Doordat mail nu als spam aangemerkt wordt begint de klant eerst bij ons te klagen waarom dat is. Die krijgt dan netjes terug dat het komt door niet juist geconfigde servers aan de verzendende kant. De klant zal dan de verzendende partij dat melden (hopen wij dan altijd). Via deze manier weet ik dat er 1 isp en 2 andere grote partijen hun mail servers wel RFC compilant gemaakt hebben. Het gaat langzaam, maar het gaat wel komen.
Of de klant gooit de venzendende partij in zijn whitelist en dan zal daar vandaan het nooit meer als spam gemarkeerd worden.
Wij hopen op de eerste situatie, maar als de andere partij niet mee wil werken dat zal de tweede voor de klant werken. In beide gavallen zal de klant zijn mail krijgen. En hoeven wij niet de keuze voor hem te maken of die wel of niet zijn mail krijgt.
@Wido
Wanneer gaan jullie je klanten verplichten om mail via jullie servers te versturen, net zoals sommige isps nu doen, om zo uitgaande spam te verminderen of virus uitbraken te controlleren? Dat lijkt me namelijk de volgende stap om te doen.
Want ook tussen jullie colo's en dedi's zullen er genoeg mail servers zitten welke niet aan de RFC's voldoen.
Alle uitgaande mail bij ons gaat al via filters die op spam controleren (alles vanaf shared-hosting).
Colo en dedi is een ander verhaal, daar zal inderdaad een hoop tussen zitten wat niet aan de RFC's voldoet, maar die krijgen ook geen whitelisting bij ons.
Ze kunnen gewoon geen mail bij ons afleveren.
crazycoder
07/05/07, 08:00
Alle uitgaande mail bij ons gaat al via filters die op spam controleren (alles vanaf shared-hosting).
Colo en dedi is een ander verhaal, daar zal inderdaad een hoop tussen zitten wat niet aan de RFC's voldoet, maar die krijgen ook geen whitelisting bij ons.
Ze kunnen gewoon geen mail bij ons afleveren.
Kortom, als zij via hun eigen server een e-mail naar jullie sturen zal die niet aankomen. Als ze zelf niet begrijpen waar ze mee bezig zijn heb je dus een kans dat ze ontevreden worden en weglopen.
Eens zien of je nog zo stoer doe als dat inderdaad gebeurt..
Doordat mail nu als spam aangemerkt wordt begint de klant eerst bij ons te klagen waarom dat is. Die krijgt dan netjes terug dat het komt door niet juist geconfigde servers aan de verzendende kant. De klant zal dan de verzendende partij dat melden (hopen wij dan altijd). Via deze manier weet ik dat er 1 isp en 2 andere grote partijen hun mail servers wel RFC compilant gemaakt hebben. Het gaat langzaam, maar het gaat wel komen.
De afzender zal zeggen dat ze nooit problemen hebben met e-mail behalve dan naar hun adressen. Dus zal het wel aan hun provider (jullie dus) liggen.
Ik heb dit soort discussies al vaak genoeg en over meerdere onderwerpen moeten voeren..
Als je echt heel erg veel geluk hebt dan zit er bij de afzender iemand die er iets van snapt en er tijd/energie in wil steken.
Of in ieder geval iemand die weet dat hij/zij er eigenlijk niets van weet maar de taak "systeembeheer" toegewezen heeft gekregen. Dan kan je ze meestal wel uitleggen wat het probleem is.
Voor de rest zal je in het MKB maar al te vaak op onwil en onkunde stuiten..
Ja, maar op die manier wordt het probleem dus nooit opgelost.
Omdat er servers losjes blijven afgestelt ziet niemand de noodzaak zijn systeem netjes te configureren.
Mijn mail komt toch aan? Waarom zou ik dan wat gaan leren over SMTP?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.
De afzender zal zeggen dat ze nooit problemen hebben met e-mail behalve dan naar hun adressen. Dus zal het wel aan hun provider (jullie dus) liggen.
Ik heb dit soort discussies al vaak genoeg en over meerdere onderwerpen moeten voeren..
Als dit een probleem blijft kunnen wij per klant de filter regels aanpassen. Uiteindelijk kunnen we daar heel flexibel in zijn omdat het systeem dat toestaat. Echter proberen wij dit niet als eerste oplossing.
En omdat wij flexibel kunnen omgaan met de rommel van andere, gelukkig zien onze klanten ook dat het om de rommel van ander gaat, hebben wij nog geen ontevreden klanten.
Kortom, als zij via hun eigen server een e-mail naar jullie sturen zal die niet aankomen. Als ze zelf niet begrijpen waar ze mee bezig zijn heb je dus een kans dat ze ontevreden worden en weglopen.
Eens zien of je nog zo stoer doe als dat inderdaad gebeurt..Dan wordt ze uitgelegt waardoor het komt.
Zulke dreigementen hebben we al vaker gehad en tot nu toe is ons beleid er niet door aangepast.
SebastiaanStok
07/05/07, 11:25
Of ik er wat tegen heb? Totaal niet :mad:
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.
Je moet is zien wat ik soms niet in het maillog vind, een of andere stomme hostname die niet eens geldig is :r
rDNS, SPF zijn dingen die helaas nog te weinig voorkomen dus je kan dit beter instelbaar maken en dan als het zo is dat ze hier niet aan voldoen dat het dan word gemarkeerd als spam.
Het "gezeur" van de klanten kan begrijpen, maar wat heb je liever een normale hoeveelheid belangrijke email of een ontplofte mailbox die stijf staat van de viagra ;)
Moeten ze is naar Hotmail gaan die, die is pas streng!!
Soms moet je de mensen gewoon dwingen om het beter te gaan doen.
Vroeger bij Windows kan je gewoon alles doen en nu heb de UAC, oke het is even wenen en had wat iets beter gemogen maar draagt toch bij een beter (stabiliteit) en (veiligheid)
Als we het toch over standaards hebben, ik heb gehoord dat MS bij IE8 nog steeds niet alle CSS standaards wil ondersteunen :eek: (Dan breken we het internet) Ja en? ik heb geen zin om met tich verschillende CSS files te gaan zitten omdat de mensen weiger op een goede manier te werken. Maak dan een optie om een oudere render engine te gebruiken als iets niet goed weergeven.
Hoef ik te minsten ook geen aparte versies op je computer zetten. :X
Edit: Typos
Het "gezeur" van de klanten kan begrijpen, maar wat heb je liever een normale hoeveelheid belangrijke email of een ontplofte mailbox die stijf staat van de viagra ;)
De klant wil gewoon zijn email welke terecht naar hem gestuurd is.
En een ontplofte mailbox? Daar hebben we de spamfilters voor die er voor zorgen dat de boel juist gemarkeerd wordt, of door de instellingen van de klant verwijderd wordt.
Dat er nu 30% extra (uitgaande mail opgave van wido) mail gescant en behandeld moet worden nemen we er dan bij. De extra resources die we daar voor nodig hebben, heeft de klant er graag voor over. Al ik kan dat makkelijk roepen omdat we niet in het budget segment zitten. Die nog geen 1% dat het duurder is om deze extra resources te betalen heeft de klant er dus voor over.
Het gaat mij hier niet om resources, maar om policy's naleven.
En ja, ik vind het ook zonde om extra CPU neer te zetten als met een simpele configuratie de spam terug kan worden gedrongen.
Het is en blijft een feit dat veel troep vanaf slecht geconfigureerde maileservers komt.
Soms moet je de mensen gewoon dwingen om het beter te gaan doen.
Ik wil best mensen gaan dwingen. Maar dan op in situaties waar die mensen zelf invloed kunnen uitoefenen. Een klant van mij die zijn mail niet kan ontvanger uit ontwil/onkunde van een verzendende partij , kan ik in geen geval dwingen.
Net zoals mijn klant dat van de verzendende partij kan doen.
Zeker als de verzendende partij weer bij een grotere firma/isp zit welke door alle regels en burocratie daar er ook niet door komt.
Het gaat mij hier niet om resources, maar om policy's naleven.
En ja, ik vind het ook zonde om extra CPU neer te zetten als met een simpele configuratie de spam terug kan worden gedrongen.
Het is en blijft een feit dat veel troep vanaf slecht geconfigureerde maileservers komt.
Zoals ook eerder gemeld leven wij zelf alle policies na bij uitgaande email. Echter kan/wil ik dat niet afdwingen bij inkomende mail omdat er nu eenmaal factoren zijn welke niet door mij, mijn klant, of een verzende partij te beinvloeden zijn. Dus zolang er nog een 'derden' partij is het spel is waar geen invloed op uit te oefenen is, kiezen wij in de belangen van mijn klant.
@Wido
Als ik je opmerkingen zo lees kies jij dus eerder voor een machine minder dan voor de belangen van je klant.
Het is uiteindelijk in het belang van de klant om de RFC's strikt na te leven! Tuurlijk, nu is het lastig omdat er soms legitieme mail door geblokkeerd wordt, maar als iedereen maar blijft wachten tot de rest het goed heeft staan, gebeurt het nooit. Als we nu als nederlandse en belgische (en andere hier op het forum aanwezige) hosting providers met z'n allen WEL netjes de RFC's gaan naleven, rustig aan beginnen en langszaam aan steeds strenger naleven, dan gaat de rest vanzelf ook mee. Zie onze "vrienden" bij hotmail, zowat alle hosting providers wringen zich door allerlei rare bochten om maar naar hotmail te kunnen mailen.. als een groot deel van de hosting providers hier ook lekker streng worden, dan zijn uiteindelijk degene die het NIET netjes doen, degene die problemen hebben.
Feit is in ieder geval wel, als we er niets aan doen, dan zal het altijd een zooitje blijven. Doen we wel wat, met zoveel mogelijk tegelijk, dan zal het zeker wel effect hebben.
crazycoder
07/05/07, 12:34
@Jurian
Wat hotmail doet heet niet streng, dat noem ik krankzinnig. E-mail verdwijnt daar naar het schijnt in het niets.
Wij hebben voor zover ik weet niet zo gek veel problemen met het verzenden naar hotmail adressen.
Als je echt iets wil doen, dan moet je het collectief afspreken, een branchevereniging zou daarbij kunnen helpen. Als vanaf een bepaald moment zo'n beetje alle providers, inclusief de groten, een geldige rdns gaan vereisen dan kan je er zeker van zijn dat je binnen korte tijd van de problemen verlost bent.
Laten we elkaar nu niet teveel voor de gek houden, rdns is een prima methode om heel veel spam te stoppen, maar het is zeker geen zilveren kogel.
Het is uiteindelijk in het belang van de klant om de RFC's strikt na te leven! Tuurlijk, nu is het lastig omdat er soms legitieme mail door geblokkeerd wordt, maar als iedereen maar blijft wachten tot de rest het goed heeft staan, gebeurt het nooit. Als we nu als nederlandse en belgische (en andere hier op het forum aanwezige) hosting providers met z'n allen WEL netjes de RFC's gaan naleven, rustig aan beginnen en langszaam aan steeds strenger naleven, dan gaat de rest vanzelf ook mee. Zie onze "vrienden" bij hotmail, zowat alle hosting providers wringen zich door allerlei rare bochten om maar naar hotmail te kunnen mailen.. als een groot deel van de hosting providers hier ook lekker streng worden, dan zijn uiteindelijk degene die het NIET netjes doen, degene die problemen hebben.
Feit is in ieder geval wel, als we er niets aan doen, dan zal het altijd een zooitje blijven. Doen we wel wat, met zoveel mogelijk tegelijk, dan zal het zeker wel effect hebben.
De hosting/isp markt is alleen te verspreid om tegelijk er wat aan te doen. Dat krijg je niet allemaal te tegelijk gemobiliseerd om dit voor elkaar te krijgen, hoe mooi het allemaal klinkt. Van mij moet iedereen zelf bepalen of die wel of niet de RFC's strict gaan afdwingen, dan zie ik vanzelf wel in mijn statistieken dat er steeds minder onjuist geconfigde servers aanwezig zijn. Ik zal er aan bijdragen dat onze servers juist geconfigureerd zijn en voor uitgaande mail zich aan de RFC houden.
Blijft voor mij zo dat ik nooit mail voor klanten zal weigeren, ongeacht de afkomst en/of inhoudt. Uiteindelijk kan alleen de klant bepalen om een mail welke binnenkomt gewenst of ongewenst is.
Ik vraag me dan alleen af, is het meerendeel van de mensen nu "bang" om hun servers strenger te maken?
Want op die manier schieten we natuurlijk niets op.
niet bang, eerder totaal geen idee waar men daadwerkelijk mee bezig is. Ik vraag me af hoeveel % de eerder genoemde settings overneemt zonder even duidelijk te zoeken wat de pro's en con's zijn....
2cts.
@crazycoder:
Helemaal mee eens, Hotmail doet gewoon belachelijke dingen. Als je ook de bekende NANOG mailing list een beetje leest, zie je dat er gewoon extreem veel mail nooit aankomt. Vooral mail van bij hotmail onbekende mailservers schijnt nogal vaak te verdwijnen. Het wordt wel geaccepteerd, maar komt nooit aan.
Filteren op zich heb ik helemaal geen probleem mee, maar reject het dan wel netjes, ipv het aan te nemen en weg te smijten, zonder dat de gebruiker kan aangeven dat ze wel degelijk alle mail willen krijgen.
En ja, natuurlijk, de hosting/isp markt is veel te verspreid om het in 1 keer te doen. Wat dat betreft zou ik zeker een voorstander zijn van meer samenwerking / overleg tussen deze partijen, om dit soort problemen eindelijk eens goed aan te kunnen pakken. Helaas is dat waarschijnlijk niet iets wat op korte termijn zal gebeuren :-(
Wat ik nog wel wil toevoegen, wij verwijderen geen mail zonder notificatie.
Of de verzender krijgt een error op SMTP niveau, er komt een bounce of hij komt in de mailbox.
Ik verkies niet een machine minder boven het belang van mijn klant, maar ik ga geen machine's onnodig hebben draaien.
Ik blijf in ieder geval bij mijn standpunt. Een beter milieu begint bij jezelf en dat vind ik hier ook op gaan.
Wat ik nog wel wil toevoegen, wij verwijderen geen mail zonder notificatie.
Of de verzender krijgt een error op SMTP niveau, er komt een bounce of hij komt in de mailbox.
Ik verkies niet een machine minder boven het belang van mijn klant, maar ik ga geen machine's onnodig hebben draaien.
Ik blijf in ieder geval bij mijn standpunt. Een beter milieu begint bij jezelf en dat vind ik hier ook op gaan.
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 .
Dit idee is op zich leuk, maar ik zie het als een supermarkt die geen briefgeld aanneemt als er een puntje af is. Wettelijk gezien staan ze vast in hun recht, maar dat is niet altijd de enige variabele waar je rekening mee moet houden.
Onze uitgaande mailserver houdt zich overigens netjes aan de verschillende RFC's, maar voor inkomend zullen we dit niet gaan doen.
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.
MediaServe
07/05/07, 14:31
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 ;)
crazycoder
07/05/07, 14:33
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>
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..
<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 :)
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?
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.
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.
SebastiaanStok
07/05/07, 15:20
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 :eek:
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.
MediaServe
07/05/07, 15:24
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.
Of ik er wat tegen heb? Totaal niet :mad:
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.)
SebastiaanStok
08/05/07, 09:39
Helo EHLO, ik haal die twee altijd door de war :o
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.
blackberry
08/05/07, 15:34
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.
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.
crazycoder
08/05/07, 15:37
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..
Afzender domein bestaat niet, dus gewoon rejecten met een permanent error.
Daarnaast, als een bedrijf serieus een systeembezweerder heeft die .local in de HELO/EHLO van z'n mailserver heeft staan, dan is de kans erg groot dat er meer mis is met zo'n mailserver. Ik zie eigenlijk totaal geen reden om mail te accepteren van .local's. Dat is net zoiets als zelf een kartonnen doos aan een paal schroeven, oranje verven, je post daarin proppen en hopen dat de TNT je "brievenbus" wel even komt legen voor je. :p
Nee. De stommeling die z'n spulletje niet goed heeft geconfigureerd.
Wij accepteren .local niet als afzender..
Over mensen gesproken die hun zaken niet op orde hebben...
May 8 07:03:30 pop001 postfix/smtpd[23398]: NOQUEUE: reject: RCPT from mail.t-mobile.nl[84.241.249.133]: 450 4.7.1 <promailgwhq-01.tm.nl.ad.tmo>: Helo command rejected: Host not found; from=<facilitairezaken@t-mobile.nl> to=<info@***.nl> proto=ESMTP helo=<promailgwhq-01.tm.nl.ad.tmo>
May 8 07:03:31 pop001 postfix/smtpd[23398]: NOQUEUE: reject: RCPT from mail.t-mobile.nl[84.241.249.133]: 450 4.7.1 <promailgwhq-01.tm.nl.ad.tmo>: Helo command rejected: Host not found; from=<facilitairezaken@t-mobile.nl> to=<***@***.nl> proto=ESMTP helo=<promailgwhq-01.tm.nl.ad.tmo>
--
May 8 07:17:58 pop001 postfix/smtpd[27341]: NOQUEUE: reject: RCPT from ip3bs.bumastemra.nl[212.78.179.247]: 450 4.7.1 <bsexcmail01.sirius.local>: Helo command rejected: Host not found; from=<*** @bumastemra.nl> to=<****@rige.net> proto=ESMTP helo=<bsexcmail01.sirius.local>
May 8 07:18:59 pop001 postfix/smtpd[23879]: NOQUEUE: reject: RCPT from ip3bs.bumastemra.nl[212.78.179.247]: 450 4.7.1 <bsexcmail01.sirius.local>: Helo command rejected: Host not found; from=<****@bumastemra.nl> to=<****@rige.net> proto=ESMTP helo=<bsexcmail01.sirius.local>
@wido:
nou heb ik net geprobeert aan te melden op dat forum op www.pcextreme.nl. Alleen komt de aanmeldings mail niet aan. Komt het omdat ik mijn server volgens de eisen werken van welke in jou openings post staan?
Received: from wscp.pcextreme.nl (www.pcextreme.nl [85.92.129.31])
by smtp1.[mxservert].nl (Postfix) with ESMTP id 8EB5DA68001
for <bakkerl@[mydomain].nl>; Tue, 8 May 2007 16:36:26 +0200 (CEST)
Jou machine roept dat die wscp.pcextreme.nl is. terwijl die het ip 85.92.129.31 gebruikt.
[bakkerl@manus ~]$ host 85.92.129.31
31.129.92.85.in-addr.arpa domain name pointer www.pcextreme.nl.
Je reverse op wscp.pcextreme.nl klopt wel.
[bakkerl@manus ~]$ host 85.92.129.32
32.129.92.85.in-addr.arpa domain name pointer wscp.pcextreme.nl.
Maar goed, mijn voorlopig eindconclusie is een fout geconfigureerde email
server (gebind aan verkeerde ip) veroorzaakt nu het niet aankomen van email.
Wat ik met deze post wil bereiken is:
- Mensen leren hoe het wel moet, hoe je je server dus moet configureren.
Postfix ging daar inderdaad met het verkeerde IP naar buiten, dat is inmiddels aangepast.
Als je die mail hebt geweigerd, dan was dat legitiem. Al vereis ik in mijn postfix niet dat jouw HELO terugkoppelt naar je rDNS.
Ik vereis dat je een geldige rDNS hebt én een HELO die een A-record heeft.
SebastiaanStok
08/05/07, 17:01
Afzender domein bestaat niet, dus gewoon rejecten met een permanent error.
Daarnaast, als een bedrijf serieus een systeembezweerder heeft die .local in de HELO/EHLO van z'n mailserver heeft staan, dan is de kans erg groot dat er meer mis is met zo'n mailserver. Ik zie eigenlijk totaal geen reden om mail te accepteren van .local's. Dat is net zoiets als zelf een kartonnen doos aan een paal schroeven, oranje verven, je post daarin proppen en hopen dat de TNT je "brievenbus" wel even komt legen voor je. :p
Ik lag helemaal dubbel van dat bericht :W: :D
Over dat commando om te controleren of de HELO werd geweigerd.
Ik krijg elke keer 0 terug :huh:
Omdat HELO hooftletter gevoelig is :o
Wel zie ik soms dit terug?
Apr 27 03:41:51 rollerscapes postfix/smtp[5773]: warning: host 127.0.1.50[127.0.1.50] replied to HELO/EHLO with my own hostname mail.rollerscapes.net
Als je die mail hebt geweigerd, dan was dat legitiem. Al vereis ik in mijn postfix niet dat jouw HELO terugkoppelt naar je rDNS.
Ik vereis dat je een geldige rDNS hebt én een HELO die een A-record heeft.
Volgens de link die in de je eerste postings staat:
PCextreme B.V. gebruikt Postfix voor haar maildiensten.
De hostname die uw server doorgeeft tijdens het HELO commando dient aan de volgende regels te voldoen:
* Het moet een FDQN zijn (bijvoorbeeld: mail.pcextreme.nl)
* De hostname moet in de DNS voorkomen (de hostname moet zijn te resolven naar een IP-Adress)
* De reverseDNS op het IP-Adres moet overeenkomen met de hostname die in het HELO commando wordt doorgegeven
Bijvoorbeeld
Uw hostname is mail.uwserver.nl. In de DNS verwijst deze hostname naar het IP-Adres 1.2.3.4
De reverseDNS van het IP 1.2.3.4 verwijst vervolgens naar mail.uwserver.nl
Het ziet er dan als volgt uit: mail.uwserver.nl -> 1.2.3.4 -> mail.uwserver.nl
Indien dit niet correct is, wordt uw server geweigerd.
pcextreme zal de mail dus wel weigeren volgens hun eigen documentatuie.
SebastiaanStok
08/05/07, 17:26
Ik heb de mail server nu ingesteld
main.cf:
myhostname = mail.rollerscapes.net
mydomain = rollerscapes.net
mydestination = $myhostname
local_recipient_maps = $alias_maps $virtual_mailbox_maps unix:passwd.byname
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl2_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,check_ recipient_access pgsql:/etc/postfix/pgsql-recipient.cf,reject_unauth_destinat
ion,permit
# The above line must be fitted in one line DONT FORGET
smtpd_sender_restrictions = check_sender_access pgsql:/etc/postfix/pgsql-sender.cf
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_client, check_client_access pgsql:/etc/postfix/pgsql-client.cf
alias_maps = pgsql:/etc/postfix/pgsql-aliases.cf
relocated_maps = pgsql:/etc/postfix/pgsql-relocated.cf
transport_maps = pgsql:/etc/postfix/pgsql-transport.cf
maildrop_destination_recipient_limit = 1
virtual_transport = maildrop
virtual_mailbox_domains = pgsql:/etc/postfix/pgsql-virtual-domains.cf
virtual_alias_maps = pgsql:/etc/postfix/pgsql-virtual.cf
virtual_mailbox_base = /data/vmail
virtual_mailbox_maps = pgsql:/etc/postfix/pgsql-virtual-maps.cf
virtual_uid_maps = pgsql:/etc/postfix/pgsql-virtual-uid.cf
virtual_gid_maps = pgsql:/etc/postfix/pgsql-virtual-gid.cf
smtpd_helo_required = yes
disable_vrfy_command = yes
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_etrn_restrictions = reject
content_filter=smtp-amavis:[127.0.0.1]:10024
# Added on 08-05-2007
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_invalid_hostname, reject_unknown_hostname
@wido:
En mag ik, als ik iets verder ga kijken, pcextreme wel mail weigeren van hun klanten omdat de mail servers zijn geconfigureerd zoals je eerder noemde, maar durft pcextreme die config zelf niet aan en laat die mail via een server lopen welke niet die rfc's afdwingt. Dit lijkt de schijn op te hebben dat pcextreme zelf geen mail wil missen hoe brak de verzendende kant ook is.
Verbeter de wereld en begin bij jezelf toch en niet bij je eigen klanten.
*mompel iets met "Eat your own dogfood"*
Mail servers voor pcextreme klanten:
[bakkerl@manus ~]$ telnet mail.pcextreme.nl 25
Trying 89.18.161.70...
Connected to mail.pcextreme.nl (89.18.161.70).
Escape character is '^]'.
220 smtp04.mail.pcextreme.nl ESMTP Postfix (PCextreme B.V.).
HELO een.niet.bestaande.hostname
250 smtp04.mail.pcextreme.nl
mail from: bakkerl@[mydomain].nl
250 Ok
rcpt to: support@pcextreme.nl
450 <een.niet.bestaande.hostname>: Helo command rejected: Host not found
rset
250 Ok
quit
221 Bye
Connection closed by foreign host.
Mail naar @pcextreme.nl adressen:
[bakkerl@manus ~]$ host -t MX pcextreme.nl
pcextreme.nl mail is handled by 10 support.pcextreme.nl.
pcextreme.nl mail is handled by 20 mx20.pcextreme.nl.
[bakkerl@manus ~]$ telnet support.pcextreme.nl 25
Trying 85.92.147.21...
Connected to support.pcextreme.nl (85.92.147.21).
Escape character is '^]'.
220 support.pcextreme.nl ESMTP Postfix (Ubuntu)
HELO een.niet.bestaande.hostname
250 support.pcextreme.nl
mail from: bakkerl@lannerd.nl
250 2.1.0 Ok
rcpt to: support@pcextreme.nl
250 2.1.5 Ok
rset
250 2.0.0 Ok
quit
221 2.0.0 Bye
Connection closed by foreign host.
ps. Dit alles is niets persoonlijk tegen Wido of PCExtreme, maar als je op een formum roept dat je het zelf allemaal zo goed doet en als goed voorbeeld wil zijn, doe het dan goed. Alleen is Wido/PCExtreme hier de topic starter en vandaar nu even het subject.
Die hebben we express nog niet aangepast zodat partijen die problemen hebben, contact op kunnen nemen met ons, wel zo handig :)
Die hebben we express nog niet aangepast zodat partijen die problemen hebben, contact op kunnen nemen met ons, wel zo handig :)
Neem dan in de URL naar de pagina waar de uitleg in staat op in het ND report, maar weiger het zelf dan ook.
Iets als in:
450 <een.niet.bestaande.hostname>: Helo command rejected: Host not found. More information about this error http://pcextreme/faqpagina
Want als 'klant' zou ik ook graag willen dat de verzende partij mij een bericht kan sturen over het eventuele probleem ;)
Beetje tegenstrijdig allemaal of je houd je aan RFC of je gaat er flexibel mee om, niet alleen wanneer het je zelf uit komt.
@ bakkerl, goed idee, dat ga ik in de config meenemen.
@ It-Biz, zoals ik aangaf, staat het express nog niet aan zodat partijen die problemen hebben, ons kunnen bereiken. Op termijn gaat het op die machine ook zeker aan.
De fallback (mx20) staat overigens al een hele tijd op deze strenge instellingen.
@Wido,
Toch nog een opmerking :)
Kun je dan ook een 5xx foutmelding terug gaan geven ipv een 4xx melding.
De 4xx serie meldingen worden gebruikt voor tijdelijke problemen. Een mail server aan de andere kant kan na een 4xx melding de mail vast houden om nogmaals op een later tijdstip te proberen.
Een melding uit de 5xx duidt op een permanent probleem. Na een 5xx melding zou er geen verdere poging tot afleveren gedaan moeten worden. Een ND/bounce report kan op dat moment direct terug gezonden worden.
De code aanpassen kan gedaan worden met
unknown_local_recipient_reject_code = 550
unknown_address_reject_code = 550
unknown_client_reject_code = 550
unknown_hostname_reject_code = 550
unknown_relay_recipient_reject_code = 550
unknown_virtual_alias_reject_code = 550
unknown_virtual_mailbox_reject_code = 550
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550
Tevens moet de soft_bounce op "no" staan. Al zou deze alleen tijdens testen op "yes" moeten staan.
Of welke je dan ook wil gebruiken.
Nee, een 5xx zou bij een tijdelijke DNS storing (aan welke zijde dan ook) er voor zorgen dat de mail direct terug bij de gebruiker in de mailbox ligt. Terwijl hij iets later misschien nog prima kan worden afgeleverd.
Maar de argumenten die jij aandraagt hebben ook weer zijn voordelen. Het is te overwegen.
crazycoder
08/05/07, 21:09
Beetje tegenstrijdig allemaal of je houd je aan RFC of je gaat er flexibel mee om, niet alleen wanneer het je zelf uit komt.
Hun servers, hun regels. :p
Ik heb een script gemaakt die mijn mail logs uitleest en in een MySQL database plaatst, ik kan nu precies zien welke hosts het meeste geweigerd worden.
Op nummer 1 tot 10 staan hosts uit Polen en Italië die met hele vreemde afzender (fhegr827@bla.com e.d.) mail proberen af te leveren.
Verder heb ik tot nu toe gezien dat Eneco een machine verkeerd geconfigureerd had staan, maar nadat ik ze even een belletje heb gegeven stond dat ook weer goed.
En daarnaast zie je wat machine's die beweren van .local te komen, maar dat zijn vooral machine's die aan DSL/Kabel lijnen hangen.
Ik vraag me dan alleen af, is het meerendeel van de mensen nu "bang" om hun servers strenger te maken?
Want op die manier schieten we natuurlijk niets op.
Waarschijnlijk de zelfde reden dat bij pcextreme de policy is aangepast om niet meer te weigeren bij een foutive HELO, maar om meer spam punten bij een foutive HELO toe te kennen.
SebastiaanStok
17/05/07, 10:16
Oke, en hoe stel je dat dan in :huh:
Postfix zelf heeft die optie niet, of moet ik dit gaan zoeken bij Spamassasing ?
Oke, en hoe stel je dat dan in :huh:
Postfix zelf heeft die optie niet, of moet ik dit gaan zoeken bij Spamassasing ?
Dit zit in spamassassin:
http://wiki.apache.org/spamassassin/Rules/FORGED_RCVD_HELO
Om het aantal punten welke deze regel hangt aan te passen kun je terug vinden in de spamassassin documentatie.
SebastiaanStok
20/05/07, 17:43
Oke ik ben er inmiddels achter hoe je het moet instellen, alleen moet ik me nog wat verdiepen in het score systeem.
Weet iemand eigenlijk hoe de rule score kan instellen als je gebruik maakt aan vitual mailling systeem in combinatie met amavis-new ?
Edit: Ik geloof dat ik het al weet :D Stond bij de handleiding iets over gebruik maken van SQL en dan dingen instellen :) Dat is zeker iets wat ik ga inbouwen in de volgende versie van het Klantpaneel.