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 ;)Citaat:
Oorspronkelijk geplaatst door Wido
Afdrukvoorbeeld
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 ;)Citaat:
Oorspronkelijk geplaatst door Wido
Zou een oplossing zijn, maar dat wil niet iedereen.Citaat:
Oorspronkelijk geplaatst door Shadowfox
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.
Als je klanten alleen e-mail uit Nederland krijgen heb je gelijk.Citaat:
Oorspronkelijk geplaatst door Jurian
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.
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!Citaat:
Oorspronkelijk geplaatst door Shadowfox
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.Citaat:
Oorspronkelijk geplaatst door jurrian
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.
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.Citaat:
Oorspronkelijk geplaatst door Wido
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?
Technisch gezien heb je gelijk.Citaat:
Oorspronkelijk geplaatst door Wido
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 en nee.Citaat:
Oorspronkelijk geplaatst door Wido
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.
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.Citaat:
Oorspronkelijk geplaatst door Wido
Eens zien of je nog zo stoer doe als dat inderdaad gebeurt..
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.Citaat:
Oorspronkelijk geplaatst door bakkerl
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..