Onderwerp: Helo name en mx records

Jammer genoeg ben ik tot de conclusie gekomen dat veel dingen die niet volgens de RFC zijn op basis van die zaken toch niet geweigerd mogen worden. Ik wil op mijn thuis server nogal eens heel graag blocken op foute ehlo/helo en geen goede reverse adresses, maar dat schijnt eigenlijk niet te mogen.

Anyway, misschien voor andere geinteresseerden nog het volgende.
In dit geval ligt de fout bij fastxs.net volgens Telfort. Heeft iets met BATV te maken.
En da's interessant want die kende ik nog niet.

Dit was het antwoord van de Telfort medewerker:

Er wordt BATV gebruikt, bounces worden ook via de NULL sender verzonden. Doordat wij proben met onze SVC, ziet BATV dit als een fout, er is immers geen tag die een bounce triggert. Dit is een anti-spam maatregel. Dit is wel in strijd met de RFC, want mail van de NULL sender mag nimmer worden geweigerd. Daarnaast leveren we feitelijk niet eens af, maar dat doet al niet meer terzake.

Dit was de test die hij deed:

Connected to mx51.emailfiltering.com.
Escape character is '^]'.
220 gse-mta-04.emailfiltering.com emfmtad 72
ehlo telfort.nl
250-gse-mta-04.emailfiltering.com Salutations 195-241-XX-XXX.ip.telfort.nl [195.241.XX.XXX].
250-AUTH DIGEST-MD5 CRAM-MD5
250-STARTTLS
250-SIZE 104857600
250 OK
mail from:<>
250 <> accepted
rcpt to:<xxxxx@computeridee.nl>
550 BATV failed

Alleen begin ik me nu af te vragen of BATV dan twee richtingen uit werkt. Want ik begrijp nu wel dat hierdoor misschien Telfort mail niet bij CID aan komt, maar het ging om mail van CID die niet bij Telfort aan kwam. Ik weet niet of dat iets uit maakt.

Als ik het goed begrijp zitten hier twee anti-spammaatregelen elkaar in weg:

- Telfort probeert het e-mailadres van de afzender te verifieren met een sender verification callout en gebruikt hiervoor als afzender het NULL-adres.
- De server waarop deze verificatie wordt uitgevoerd accepteert geen e-mail van de NULL-sender als deze niet gericht is aan een specifiek getagd e-mailadres. Als gevolg faalt de verificatie en weigert Telfort de e-mail.
- In beide gevallen wordt er kennelijk direct een hard fail (500-code) gegeven ipv een soft fail (400-code) waardoor de e-mail direct bouncet.

Hoewel BATV in strijd is met RFCs is SVC imho meer diabolisch. BATV is bedoeld om het probleem van backscatter aan te pakken en zal normaliter vrijwel geen overlast veroorzaken. SVC is volgens mij niet in strijd met RFCs maar verplaatst een deel van de overlast van spam naar onschuldige derden en, erger nog, lost het 'probleem' van niet-bestaande afzenderadressen niet op (spammers gebruiken vaak bestaande e-mailadressen van onschuldige derden).

Als Telfort gebruik maakt van SVC dan zou ik adviseren om dat e-mailadres gewoon niet meer te gebruiken omdat dit allerlei soorten problemen gaat opleveren.

Oorspronkelijk geplaatst door Blacky

Alleen begin ik me nu af te vragen of BATV dan twee richtingen uit werkt. Want ik begrijp nu wel dat hierdoor misschien Telfort mail niet bij CID aan komt, maar het ging om mail van CID die niet bij Telfort aan kwam. Ik weet niet of dat iets uit maakt.

Dit is inderdaad een bug in hun BATV implementatie. BATV moet nooit toegepast worden op NULL senders.

Bedankt, dan ga ik ze nog eens daarop wijzen.