SMTP communicatie, reverse DNS & antispam maatregelen

[jwpmzijl]

Ik wil jullie mening vragen over het volgende.
^{Het is wellicht een lang verhaal maar daarmee hoop ik geen vraagtekens achter te laten (en te voorkomen dat Koffie zijn voorraad slotjes aanspreekt ).}
Ik beheer een 10-tal Exchange servers (2000 en 2003) bij voornamelijk kleine bedrijven. Bij al deze bedrijven is een ADSL verbinding met een vast IP-adres. Het MX-record van de bijbehorende domeinen verwijst vervolgens naar het IP-adres van de ADSL aansluiting bij het betreffende bedrijf. Uiteraard wordt in de lokale firewall een port-forward naar het interne IP-adres van van mailserver gemaakt. De exchange servers zijn zo geconfigureerd dat ze géén smarthost voor de verzending gebruiken. Deze configuratie werkt tot nu toe zonder grote problemen.

Echter bij één klant heb ik het probleem dat men géén E-mail naar een bepaald domein kan sturen. Het eerste wat je dan denkt is dat die ontvanger een SPAM-filter met blacklist o.i.d. gebruikt en dat het IP-adres van de mailserver van de verzender op die zwarte lijst voorkomt. Dus neem je contact op met de systeembeheerder van de ontvanger en dan blijkt dat dit niet het geval is.

Je gaat verder kijken en achterhaald welke server de E-mail afhandelt voor het domein en vervolgens bel je met de provider van die mail-server. Daar krijg je in eerst instantie te horen dat alles goed is met hun mailserver. Na enig aandringen (je laat blijken niet helemaal onbekend te zijn met SMTP-communicatie) komt men met een volgende opmerking:

• De reverse DNS van de mailserver van mijn klant is niet goed ingesteld en daarom wordt de mailserver van mijn klant geblokkeerd
  bijv:
• IPadres ADSLrouter = 100.100.100.2
• Hostnaam bij dit IPadres = node12345.vpt.adsl.hostingbedrijf.nl
• mail.bedrijfx.nl verwijst naar 100.100.100.2
• Doet men een tracert op 100.100.100.2 dan zou gezocht moeten worden naar mail.bedrijfx.nl maar het is op dit moment node12345.vpt.adsl.hostingbedrijf.nl

Deze is nieuw voor mij. En ik vraag mij af in hoeverre dit conform het SMTP-protocol is. Zo kwam ik er ook achter dat deze provider SMTP-communicatie via het telnet protocol niet toestaat. Hoe kun je nu in godsnaam testen waar het probleem zit (mail.stablestream.net).

Ik begrijp best dat ANTI-spam maatregelen noodzakelijk zijn maar ben mening dat deze provider zijn taken iets te serieus neemt mail.stablestream.net.

Hebben jullie dit probleem al eens aan de hand gehad?

• [sup]
• Overigens het aanpassen van de reverse DNS is al aangevraagd. Het moet nog blijken of dit de oplossing is
• [/sup]

[DGTL_Magician]

jwpmzijl schreef op vrijdag 05 mei 2006 @ 10:03:
...

Daar is SPF voor uitgevonden.
Je moet in je DNS een SPF record aanmaken, dit is een aanvulling op de SMTP standaard.
Zie voor meer informatie: http://www.openspf.org/

In je SPF record geef je namelijk aan welke servers er mail mogen versturen voor jouw domein. Daar controleerd zo'n ontvangende mailserver dan op.

[ Voor 79% gewijzigd door DGTL_Magician op 05-05-2006 10:28 ]

[Verwijderd]

DGTL_Magician schreef op vrijdag 05 mei 2006 @ 10:27:
[...]

Daar is SPF voor uitgevonden.
Je moet in je DNS een SPF record aanmaken, dit is een aanvulling op de SMTP standaard.
Zie voor meer informatie: http://www.openspf.org/

In je SPF record geef je namelijk aan welke servers er mail mogen versturen voor jouw domein. Daar controleerd zo'n ontvangende mailserver dan op.

Dit lijkt me toch wat de provider doet ook.
Maar eh, ondersteunt bijvoorbeeld Exchange SPF denk je?
Eignelijk lijkt me de discussie dus meer: hoe slim is het om dit soort maatregelen toe te passen ivm compatibility met andere bedrijven?

[wizzzzzz]

Waarom maak je geen gebruik van een smarthost. Ik heb al vaker problemen gezien met het weigeren van email door sommige providers omdat het van een niet reguliere mailserver afkomt.
Ik stel dus voortaan altijd in dat de mail via de mailserver van de provider wordt verstuurd, via smarthost dus.

[jwpmzijl]

SPF klinkt als een goede methode om misbruik tegen te gaan (ik had er nog niet van vernomen). Probleem is natuurlijk dat het hier een kip en ei verhaal betreft.

• Er zijn nog weinig domeinen die SPF records in hun DNS hebben staan en daaarom (kunnen) providers nog niet probleemloos gebruik maken van SPF en omdat SPF nog niet veel gebruikt wordt is de noodzaak om SPF records in DNS op te nemen niet erg groot.

[ Voor 6% gewijzigd door jwpmzijl op 05-05-2006 11:07 ]

[Qwerty-273]

AOL is de bekende die gebruik maakt van rDNS, ze hebben op hun support pagina wel het een en ander daar over staan (aantal klanten van ons hebben een AOL adres - http://postmaster.aol.com/info/rdns.html ). En daar kan je testen of ze de mail inderdaad wel of niet accepteren.

Vervolgens op http://relays.osirusoft.com/cgi-bin/rdns.cgi kan je de rdns controleren of ie wel of niet werkt. En meestal kan je je provider vragen om een juiste rdns in te stellen, zodat node12345.vpt.adsl.hostingbedrijf.n veranderd wordt naar mail.bedrijfx.nl.

[jwpmzijl]

wizzzzzz schreef op vrijdag 05 mei 2006 @ 10:57:
Waarom maak je geen gebruik van een smarthost. Ik heb al vaker problemen gezien met het weigeren van email door sommige providers omdat het van een niet reguliere mailserver afkomt.
Ik stel dus voortaan altijd in dat de mail via de mailserver van de provider wordt verstuurd, via smarthost dus.

Smarthost is inderdaad een veilige methode om problemen met DNS configuraties te omzeilen. Echter mijn klanten verzenden mailings naar enkele honderden leden/klanten (let wel klanten/leden die zich tegen betaling hebben aangemeld voor die mailings - ABSOLUUT géén SPAM dus). Internet providers als bijv. Euronet en Tiscali accepteren dat niet.
Ik kan dus (helaas) geen gebruik maken van een smarthost.

[paulhekje]

reverse dns correct instellen is inderdaad de juiste oplossing hier.
Vaak wordt reverse dns meegenomen om de spam-rating te berekening door anti-spam pakketten, maar mail weigeren alleen om deze reden gebeurt niet zo vaak.

[CyBeR]

jwpmzijl schreef op vrijdag 05 mei 2006 @ 10:03:
Zo kwam ik er ook achter dat deze provider SMTP-communicatie via het telnet protocol niet toestaat. Hoe kun je nu in godsnaam testen waar het probleem zit (mail.stablestream.net).

Dit is iig onzin. Op zich klopt 't wel maar d'r zit een soort appel-peer probleem. Telnet en SMTP zijn beide protocollen, en het een doe je niet via het ander. Als jij telnet naar een mailserver zal die je weinig info geven. Maar 't mooie is dat de meeste telnet clients ook gewone (niet-telnet) tcp verbindingen op kunnen zetten. En dan is er geen verschil tussen dat en een MUA of MTA die naar een mailserver connect. Hoogstens loop je als je zelf typt tegen een timeout aan.

[jwpmzijl]

CyBeR schreef op vrijdag 05 mei 2006 @ 11:55:
[...]
Maar 't mooie is dat de meeste telnet clients ook gewone (niet-telnet) tcp verbindingen op kunnen zetten. En dan is er geen verschil tussen dat en een MUA of MTA die naar een mailserver connect. Hoogstens loop je als je zelf typt tegen een timeout aan.

De win XP telnet cliënt gebruik ik inderdaad als "manusje van alles" om verbindingen te testen. Wellicht niet helemaal volgens de regels maar het werkt wel. De mailserver bij Stablestream is de eerste die ik tegenkom welke een controle uitvoert op het gebruikte protocol.

[Sendy]

Cyber heeft gelijk. Als jij in je telnet client het protocol goed intikt, dan kan de ontvanger helemaal niet zien dat je geen echte MTA gebruikt. De ontvangen bytes zijn volkomen dezelfde.

Verder snap ik het probleem niet echt. Jouw MTA (op 100.100.100.2) stuurt een EHLO mail.bedrijfx.nl. De ontvanger vertrouwt jou niet direct en doet een reverse DNS call op je ip. Hier komt uit node12345.vpt.adsl.hostingbedrijf.nl. Omdat "mail.bedrijfx.nl" <> "node12345.vpt.adsl.hostingbedrijf.nl" wordt de e-mail geblokt?

In RFC2821 kan ik niet zo snel vinden dat dat niet toegestaan, maar er staat ook niet dat het geweigerd mag worden. Dus lijkt het mij dat de onvanger zichzelf blij kan maken door zulke EHLO's gewoon te accepteren, en alleen een fijne logregel moet schrijven.

Ik lees wel het volgende

4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)

These commands are used to identify the SMTP client to the SMTP
server. The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system. y The SMTP server identifies itself to the SMTP
client in the connection greeting reply and in the response to this
command.

Jij zou dus eigenlijk iets als "EHLO [100.100.100.2]" moeten sturen. Hoe dat optionally geinterpreteerd dient te worden weet ik niet. Een "EHLO [100.100.100.2] hostbedrijf.nl" wordt in ieder geval niet geaccepteerd door mijn (exim) SMTP server.

edit:

Ik snap dat mensen SPAM willen blocken, maar dan zou je niet volledig op zo'n onhandige EHLO moeten afgaan. Een systeem zoals paulhekje beschrijft is dan beter.

edit:

In de exim 4 handleiding staat trouwens het volgende bij de optie om in te stellen dat zulke e-mail geblokt moet worden
[quote]
helo_try_verify_hosts
Type: host list, expanded
Default: unset

The RFCs mandate that a server must not reject a message because it doesn't like the HELO or EHLO command. By default, Exim just checks the syntax of these commands (see helo_accept_junk_hosts and helo_allow_chars above). However, some sites like to be stricter. If the calling host matches helo_try_verify_hosts, Exim checks that the host name given in the HELO or EHLO command either:

* is an IP literal matching the calling address of the host (the RFCs specifically allow this), or
* matches the host name that Exim obtains by doing a reverse lookup of the calling host address, or
* when looked up using gethostbyname() (or getipnodebyname() when available) yields the calling host address.

However, the EHLO or HELO command is not rejected if any of the checks fail. Processing continues, but the result of the check is remembered, and can be detected later in an ACL by the verify = helo condition. If you want verification failure to cause rejection of EHLO or HELO, use helo_verify_hosts instead.
[/quote]

Dus misschien staat er dus wel zoiets in de RFC.

[ Voor 36% gewijzigd door Sendy op 05-05-2006 13:02 ]

[ChaserBoZ_]

Het is weer een stukje moeilijker maken voor o.a. spammers enz, in de zin van 'heb je de moeite er niet voor over om een rDNS te regelen, DAN bekijk je het maar met je mail'. Een hele hoop onwetende eigenaren van open relay bakken hebben dit niet, en daavoor ben je dan bestand.

Ik ben voor deze maatregel van antispam

[Wunk]

plus 't feit dat een hoop mailservers simpelweg mail niet accepteren welke van een ADSL/Cable range af komt..

[jwpmzijl]

Wunk schreef op vrijdag 05 mei 2006 @ 20:51:
plus 't feit dat een hoop mailservers simpelweg mail niet accepteren welke van een ADSL/Cable range af komt..

Whohooo, dit is een wel hele stellige bewering, ik draai al enkele jaren Exchange servers vanaf ADSL verbindingen en dit is de eerste keer dat ik meemaak dat E-mail geweigerd wordt. Nu moet ik er wel bij zeggen dat 99% van de E-mail die mijn relaties verzenden binnen Nederland blijft.

Dus graag enkele voorbeelden van mailservers die bij een foutieve rDNS inderdaad blokkeren.

[P5ycho]

een goed voorbeeld is de batterij mailservers van @home, laatst hebben ze blijkbaar een aanpassing gedaan waardoor een 'rare' rDNS niet geaccepteerd wordt:

code:

Wed 2006-02-08 10:45:59: <-- 550-Spam refused: 84-245-*-*.dsl.cambrium.nl is a silly name for a mail
Wed 2006-02-08 10:45:59: <-- 550 server or server has no name.

Was vergeten een reverse DNS aan te vragen na lijnmigratie.

[Sendy]

Raar voorbeeld P5ycho. Wat is hun definitie van silly names? Zonder die definitie zou ik toch niet weten welke naam mijn server dan moet krijgen?

Als mijn ip zo'n leuke naam zou hebben zou @home mooi mogen stikken in mijn e-mail, en ik zou iedereen afraden bij @home te gaan.

edit:

NOFI ChazerBoz_, maar gokken kan ik ook. Zou smtpa.afdelingb.bedrijfc.com.kr e-mail mogen sturen naar @home?

[ Voor 20% gewijzigd door Sendy op 07-05-2006 20:22 ]

[Guru Evi]

Ik heb dit ook al redelijk veel tegengekomen. Het is soms niet aanvaardbaar, maar meestal kun je ook niet zeggen, stik maar in je mail (afhankelijk van je klant).

Er is in duitsland zo'n provider die enorm anal is met het accepteren van mail (meestal vanaf shared servers met meerdere domeinen op hetzelfde IP). Ik zou het persoonlijk niet blokkeren, maar spamassassin geeft bij mij wel een hogere score.

Wat je kunt doen is een PTR record aanvragen bij je provider, een goed SPF record in de domein steken en het uitgaande domein op de server ook correct instellen. Of het nu geaccepteerd wordt in een RFC of niet, het is bijna onmogelijk om de administrators aan de andere kant van het tegendeel te overtuigen. SMTP en e-mail is nu eenmaal enorm open voor interpretatie mede vanwege SPAM, Exchange- en Outlook-specific headers en evolutie op het Internet. SMTP is bedacht in de jaren 70 en nooit upgedate. Zou ongeveer hetzelfde zijn moesten we nog allemaal surfen met Gopher.

[ChaserBoZ_]

Sendy schreef op zaterdag 06 mei 2006 @ 13:33:
Raar voorbeeld P5ycho. Wat is hun definitie van silly names? Zonder die definitie zou ik toch niet weten welke naam mijn server dan moet krijgen?

Als mijn ip zo'n leuke naam zou hebben zou @home mooi mogen stikken in mijn e-mail, en ik zou iedereen afraden bij @home te gaan.

Ik vermoed dat silly names in hun optiek namen zijn die niet simpelweg a.b.c zijn, en/of teveel sub-sub-subdomeinen etc.

[CyBeR]

ChaserBoZ_ schreef op zondag 07 mei 2006 @ 17:22:
[...]


Ik vermoed dat silly names in hun optiek namen zijn die niet simpelweg a.b.c zijn, en/of teveel sub-sub-subdomeinen etc.

Silly names zijn waarschijnlijk namen met 'dsl', 'cable', 'dial', etc. erin.

[Bastien]

P5ycho schreef op vrijdag 05 mei 2006 @ 22:07:
een goed voorbeeld is de batterij mailservers van @home, laatst hebben ze blijkbaar een aanpassing gedaan waardoor een 'rare' rDNS niet geaccepteerd wordt:

code:

Wed 2006-02-08 10:45:59: <-- 550-Spam refused: 84-245-*-*.dsl.cambrium.nl is a silly name for a mail
Wed 2006-02-08 10:45:59: <-- 550 server or server has no name.

Was vergeten een reverse DNS aan te vragen na lijnmigratie.

Als ik 84-245-*-*.dsl.cambrium.nl als hostname instel, accepteert @home de email wel. Als ik het subdomein invoer welke ik voor de mailserver gebruik, accepteert ie het niet. De rDNS is inderdaad niet kloppend dan.

Dit doet iig @home al enige tijd. Maar ik heb de mailserver zo ingesteld dat als ie het zelf niet mag afleveren, het alsnog via de smarthost (tweakdsl dus) gaat. Komt het toch nog over.

CyBeR schreef op zondag 07 mei 2006 @ 22:16:
[...]


Silly names zijn waarschijnlijk namen met 'dsl', 'cable', 'dial', etc. erin.

Dat niet altijd denk ik... volgens mij gaan ze niet verder dan hostname-IP vergelijken bij @home.

[ Voor 15% gewijzigd door Bastien op 07-05-2006 23:05 ]

[Verwijderd]

Ik heb ook het probleem met mailen naar @home ook geeft hij de fout:
550-Spam refused: ******* is a silly name for a mail
550 server or server has no name.

Nu heb ik een small business server. Wat moet ik doen?

[Equator]

Verwijderd schreef op vrijdag 07 juli 2006 @ 17:39:
Ik heb ook het probleem met mailen naar @home ook geeft hij de fout:
550-Spam refused: ******* is a silly name for a mail
550 server or server has no name.

Nu heb ik een small business server. Wat moet ik doen?

Je mail versturen via een smarthost of je reverse DNS laten regstreren op jouw IP adres.

Dat is in korte lijnen datgene wat er gezegd wordt in het topic.. Of heb je dat niet gelezen

[Verwijderd]

Ja ik heb wel gelezen maar er staat ook dit:
De reverse DNS van de mailserver van mijn klant is niet goed ingesteld en daarom wordt de mailserver van mijn klant geblokkeerd

En nu zeg jij dat ik dit moet laten doen, dan is mijn vraag, hoe?

[alt-92]

Verwijderd schreef op zaterdag 08 juli 2006 @ 10:26:

En nu zeg jij dat ik dit moet laten doen, dan is mijn vraag, hoe?

Bellen?

[edit]
Ok, uitgebreider:
Je wil bij je ISP een reverse DNS entry hebben voor <mailhostname>.domain.tld zoals je die ook in je Fwd DNS lookup zone hebt staan.

[ Voor 31% gewijzigd door alt-92 op 08-07-2006 11:01 ]

[Lex_brugman]

Zodra jij een smarthost gebruikt maakt je reverse dns niets meer uit.

[hessel]

Henk van de Kamer (het lab, PC-Active)
Heeft hier ooit ook het een en ander over geschreven/uitgelegd.
http://www.hetlab.tk/labjournaal/200404.php en http://www.hetlab.tk/foru...3d03489d74a6f0b5baee79b64
Zou zeggen lees het eens door ... En ga het indien mogelijk gebruiken. Voor een beheerde van een domain is het maar weinig werk om in te stellen, zodat je mail altijd weg komt. Ga je het ook gebruiken voor ontvangst dan moet je hellaas iets meer doen, Mogelijk is het de moeite waard.

[Verwijderd]

Waar kan ik dan een smarthost instellen bij SBS2003? Ik heb met smarthosts echt geen ervaring..

[Equator]

Je kan bij de SMTP opties 2 mogelijkheden instellen:
- verstuur mail via DNS (dit geeft problemen wanneer je reverse lookup niet klopt)
- verstuur via relay/smarthost (vul hier het ip adres of fqdn in van de smtp server van je provider)

[curry684]

DGTL_Magician schreef op vrijdag 05 mei 2006 @ 10:27:
[...]

Daar is SPF voor uitgevonden.
Je moet in je DNS een SPF record aanmaken, dit is een aanvulling op de SMTP standaard.
Zie voor meer informatie: http://www.openspf.org/

In je SPF record geef je namelijk aan welke servers er mail mogen versturen voor jouw domein. Daar controleerd zo'n ontvangende mailserver dan op.

Even een kleine trap omdat ik dit een heel irritant probleem vind. Ik ben momenteel bezig met het verplaatsen van een stuk of 30 domains, en allemaal hebben ze hetzelfde probleem. Vanzelfsprekend geef ik de SMTP-server en de webmailhost de correcte rDNS bij hun fDNS bij hun hostname zoals Postfix zich kenbaar maakt, maar met SPF zit ik toch wat in m'n maag.

Stel de extreem met mij vergelijkbare situatie hier op Tnet: 125 man crew met een @tweakers.net mailadres, en allemaal ontvangen ze die mail netjes via POP3 of IMAP, maar versturen doen ze merendeels via de SMTP van hun eigen provider. Dan is het dus tenzij je netjes bijhoudt wie welke provider heeft bijkans onmogelijk om een ander SPF-record aan te maken dan:

code:

v=spf1 +all

Maar dat ademt weer zo hard uit "spam in mijn naam asjeblieft want ik heb iedere massmailer op de wereld zojuist toestemming gegeven". Is het in zo'n situatie niet gewoon beter om de domains op een verder well-behaving mailserver gewoon geen SPF te geven dan een all-is-fine? Hoeveel mailproviders werken er nu intussen eigenlijk mee? Hoe zwaar wordt het gebrek aan SPF aangerekend?

[ Voor 3% gewijzigd door curry684 op 25-07-2006 08:56 ]

[DGTL_Magician]

curry684 schreef op dinsdag 25 juli 2006 @ 08:55:
[...]

Even een kleine trap omdat ik dit een heel irritant probleem vind. Ik ben momenteel bezig met het verplaatsen van een stuk of 30 domains, en allemaal hebben ze hetzelfde probleem. Vanzelfsprekend geef ik de SMTP-server en de webmailhost de correcte rDNS bij hun fDNS bij hun hostname zoals Postfix zich kenbaar maakt, maar met SPF zit ik toch wat in m'n maag.

Stel de extreem met mij vergelijkbare situatie hier op Tnet: 125 man crew met een @tweakers.net mailadres, en allemaal ontvangen ze die mail netjes via POP3 of IMAP, maar versturen doen ze merendeels via de SMTP van hun eigen provider. Dan is het dus tenzij je netjes bijhoudt wie welke provider heeft bijkans onmogelijk om een ander SPF-record aan te maken dan:

code:

v=spf1 +all

Maar dat ademt weer zo hard uit "spam in mijn naam asjeblieft want ik heb iedere massmailer op de wereld zojuist toestemming gegeven". Is het in zo'n situatie niet gewoon beter om de domains op een verder well-behaving mailserver gewoon geen SPF te geven dan een all-is-fine? Hoeveel mailproviders werken er nu intussen eigenlijk mee? Hoe zwaar wordt het gebrek aan SPF aangerekend?

Dat is zo. Maar voor mijn personeel zou ik toch verplichten dat ze webmail gebruiken of een authenticated SMTP server van het bedrijf. Op die manier kun je ook duidelijker ondersteuning bieden aan je personeel, immers je weet de ins and outs van de ISP mailservers niet.

Dit is ook de manier waarop de OpenSPF het aanraadt:
http://www.openspf.org/forsysadmins.html

Er zijn sommige mailservers die geen mail ontvangen van non-SPF mailers. Maar dat is zo ontzettend weinig dat je je postmaster mail wel na kan kijken als je klachten krijgt. Als je mailserver setup voor de rest gezond is met rDNS en fDNS dan moet het in orde komen.

[ Voor 9% gewijzigd door DGTL_Magician op 25-07-2006 11:08 ]

[blaataaps]

curry684 schreef op dinsdag 25 juli 2006 @ 08:55:
[...]


Stel de extreem met mij vergelijkbare situatie hier op Tnet: 125 man crew met een @tweakers.net mailadres, en allemaal ontvangen ze die mail netjes via POP3 of IMAP, maar versturen doen ze merendeels via de SMTP van hun eigen provider. Dan is het dus tenzij je netjes bijhoudt wie welke provider heeft bijkans onmogelijk om een ander SPF-record aan te maken dan:

code:

v=spf1 +all

Dit is ook precies waarom SPF gewoon een slecht idee is; In veel gevallen is het gewoon onhaalbaar te eisen dat men via een beperkte, continue geadministreerde set mailservers mailt. Op dat moment is een ALL-record ongeveer de enige oplossing. Aan de ontvangende kant heb je er weer niks aan SPF te eisen (of wel accepteren maar hoger raten als spam) als iedereen in plaats van geen SPF gewoon een record voor ALL maakt.
Uiteindelijk ben je dan netto niks opgeschoten ten opzichte van een situatie zonder SPF, behalve dat je een paar nutteloze records rijker bent

Maar dat ademt weer zo hard uit "spam in mijn naam asjeblieft want ik heb iedere massmailer op de wereld zojuist toestemming gegeven".

Mjah, echt veel verlies je niet ten opzichte van een impliciete toestemming door geen SPF te doen denk ik. Sowies werkt SPF alleen maar op de envelope from volgens mij, dus niemand houdt mij in welk geval dan ook tegen om gewoon "mail from: <[e-mail]>" te doen, en vervolgens een "From: curry@ketchup" neer te zetten, ook al heb je een restrictieve SPF-record voor het ketchup-domein. De SPF klopt dan, en de meeste gebruikers zien niks anders dan "oh, de mail komt van curry".

Is het in zo'n situatie niet gewoon beter om de domains op een verder well-behaving mailserver gewoon geen SPF te geven dan een all-is-fine? Hoeveel mailproviders werken er nu intussen eigenlijk mee? Hoe zwaar wordt het gebrek aan SPF aangerekend?

De mailers die een gebrek aan SPF zwaar aanrekenen zijn in mijn opinie fout bezig (koop je niks voor als je mail niet aankomt natuurlijk). Op het moment dat je last krijgt van dergelijke mafkezen zou ik ze gewoon blijmaken met een record waarin je alles toestaat, zij blij, jij blij want je mail komt aan. Alleen jammer natuurlijk dat het jou tijd kost om hun keuzes op te lossen.

[ Voor 9% gewijzigd door blaataaps op 25-07-2006 11:26 ]

[curry684]

blaataaps schreef op dinsdag 25 juli 2006 @ 11:24:
[...]

Sowies werkt SPF alleen maar op de envelope from volgens mij, dus niemand houdt mij in welk geval dan ook tegen om gewoon "mail from: <[e-mail]>" te doen, en vervolgens een "From: curry@ketchup" neer te zetten, ook al heb je een restrictieve SPF-record voor het ketchup-domein. De SPF klopt dan, en de meeste gebruikers zien niks anders dan "oh, de mail komt van curry".

Als het alleen op de envelope werkt is het wel een enorm lek concept, want dan gaat iedere spammer gewoon zoeken naar de eerste de beste SPF-record die niet hardfailt als final rule, en dan vervolgens al z'n spam versturen met als MAIL FROM de [e-mail] account, of ben ik nu gek? Dan krijg je dus een kat en muis spelletje met spammers die dagelijks nieuwe domains zoeken en sysadmins die verplicht overal auth-SMTP op moeten aanbrengen en als een gek SPF-records moeten aanmaken.

[blaataaps]

curry684 schreef op dinsdag 25 juli 2006 @ 12:32:
[...]

Als het alleen op de envelope werkt is het wel een enorm lek concept,

Dat is het ook
http://en.wikipedia.org/wiki/Sender_Policy_Framework#Caveats
Bij de voordeur checken op een From: header is ook niet zonder meer een goed idee denk ik trouwens

want dan gaat iedere spammer gewoon zoeken naar de eerste de beste SPF-record die niet hardfailt als final rule, en dan vervolgens al z'n spam versturen met als MAIL FROM de [e-mail] account, of ben ik nu gek?

En dat zijn er genoeg, omdat iedereen die geen SPF wil maar toch moet, gewoon een "allow all" record maakt

Dan krijg je dus een kat en muis spelletje met spammers die dagelijks nieuwe domains zoeken en sysadmins die verplicht overal auth-SMTP op moeten aanbrengen en als een gek SPF-records moeten aanmaken.

Of iedereen maakt zodra hotmail SPF wil voor inkomende mail een record voor ALL aan, en is SPF nutteloos geworden

[igmar]

curry684 schreef op dinsdag 25 juli 2006 @ 08:55:
Stel de extreem met mij vergelijkbare situatie hier op Tnet: 125 man crew met een @tweakers.net mailadres, en allemaal ontvangen ze die mail netjes via POP3 of IMAP, maar versturen doen ze merendeels via de SMTP van hun eigen provider. Dan is het dus tenzij je netjes bijhoudt wie welke provider heeft bijkans onmogelijk om een ander SPF-record aan te maken dan:

code:

v=spf1 +all

Ja en nee. SPF werkt niet, vooral het 'probleem' mailinglist is niet afdoende opgelost. Aan de andere kant is het op het moment het enige beetje geaccepteerde idee. Ik dring zelf wel aan op verzenden via AUTH SMTP, en ik kan me eigenlijk geen reden verzinnen waarom niet : Elke fatsoenlijke MUA kan per account een uitgaande MTA opgeven, en AUTH SMTP is tegenwoordig de normaalste zaak van de wereld.

Echt, je wil je mail niet overleveren aan een stelletje prutsers zoals Planet / Tiscali.

Maar dat ademt weer zo hard uit "spam in mijn naam asjeblieft want ik heb iedere massmailer op de wereld zojuist toestemming gegeven". Is het in zo'n situatie niet gewoon beter om de domains op een verder well-behaving mailserver gewoon geen SPF te geven dan een all-is-fine? Hoeveel mailproviders werken er nu intussen eigenlijk mee? Hoe zwaar wordt het gebrek aan SPF aangerekend?

Ik merk d'r eigenlijk weinig van. Ik heb nu niet de indruk dat SPF nu erg veel gebruikt word, alleen SPF records leveren je wel een betere spamassassin score op :-) Ik negeer het al tijden zonder noemenswaardige problemen.

[rdfeij]

Bastien schreef op zondag 07 mei 2006 @ 23:02:
[...]
Als ik 84-245-*-*.dsl.cambrium.nl als hostname instel, accepteert @home de email wel. Als ik het subdomein invoer welke ik voor de mailserver gebruik, accepteert ie het niet. De rDNS is inderdaad niet kloppend dan.

Dit doet iig @home al enige tijd. Maar ik heb de mailserver zo ingesteld dat als ie het zelf niet mag afleveren, het alsnog via de smarthost (tweakdsl dus) gaat. Komt het toch nog over.


[...]
Dat niet altijd denk ik... volgens mij gaan ze niet verder dan hostname-IP vergelijken bij @home.

Voor zover ik weet heeft @home ook poort 25 dichtstaan (iig particulier gebruik) in hun regelementen staat ook dat mailservers ( die niet relayen via hun eigen mailservers...smarthost.... )aan hun netwerk niet zijn toegestaan.

[igmar]

rdfeij schreef op vrijdag 28 juli 2006 @ 09:57:
Voor zover ik weet heeft @home ook poort 25 dichtstaan (iig particulier gebruik) in hun regelementen staat ook dat mailservers ( die niet relayen via hun eigen mailservers...smarthost.... )aan hun netwerk niet zijn toegestaan.

reverse DNS checks helpen niet : Het probleem is gebruikers met een trojan op hun PC die vrolijk als open proxy fungeren. En die hebben vanuit de ISP al een kloppende forward / reverse gekregen.

[Verwijderd]

blaataaps schreef op dinsdag 25 juli 2006 @ 11:24:
[...]
Dit is ook precies waarom SPF gewoon een slecht idee is; In veel gevallen is het gewoon onhaalbaar te eisen dat men via een beperkte, continue geadministreerde set mailservers mailt. Op dat moment is een ALL-record ongeveer de enige oplossing. Aan de ontvangende kant heb je er weer niks aan SPF te eisen (of wel accepteren maar hoger raten als spam) als iedereen in plaats van geen SPF gewoon een record voor ALL maakt.
Uiteindelijk ben je dan netto niks opgeschoten ten opzichte van een situatie zonder SPF, behalve dat je een paar nutteloze records rijker bent

je kan natuurlijk ook een spamwaarde toekennen aan domains met ALL spf records.
Het feit dat je kan relayen via een isp met een andere domain naam is eigenlijk al verkeerd, maar ook weer logisch gezien uit het oogpunt van de isp.

[blaataaps]

Verwijderd schreef op vrijdag 28 juli 2006 @ 12:02:
[...]


je kan natuurlijk ook een spamwaarde toekennen aan domains met ALL spf records.

Natuurlijk kan dat, maar dat betekent nog niet dat het zinvol is :)[quote
Het feit dat je kan relayen via een isp met een andere domain naam is eigenlijk al verkeerd, maar ook weer logisch gezien uit het oogpunt van de isp.[/quote]
Waarom is dat verkeerd?

[Verwijderd]

het feit dat een isp alle sender domains toestaat... je zou liever hebben dat isps vragen om de sender domains op te geven zodat ze ook op senderdomain kunnen restricten.. maar ik begrijp ook wel dat dit niet haalbaar is...

[wietse.cc]

Ik ben er nu zelf ook tegenaan gelopen, sinds ik door klanten ben gebeld dat ze ineens hun uitgaande mail via hun managed dedicated server niet meer kunnen versturen. "Ligt de SMTP server plat!?"...

Het was opvallend dat via de ene provider het wel werkte, via de andere niet. Inderdaad; Uitgaande SMTP block naar alle servers behalve die van de provider zelf.

Heel vervelend is alleen dat op deze manier heel SPF om zeep wordt geholpen, mensen gaan vanaf hun [e-mail] sturen via de SMTP servers van hun eigen provider, en het is onmogelijk met al die verschillende servers binnen de verschillende providers nog een goed werkende SPF bij te houden. (Nu was SPF toch al einde verhaal door header-injection e.d.) maar toch; SPF voor klantdomeinen kan op deze manier niet meer.

Natuurlijk zal het best h.e.e.a. aan spam-mails voorkomen, maar voor mensen met een eigen domein, mensen die wat 'bovengemiddeld' gebruik maken van het internet, is dit wel zeer ellendig...