Sender ID werkt niet voor Authorative domain op Exch 2007

[Robbeke]

Tweakers,

Zie hier de opzet van onze installatie:

• Split DNS: interne DNS en DNS bij provider voor hetzelfde domein. (voorbeeld.be)
• Exchange server met authorative domein voorbeeld.be
• In public DNS staan de MX records geconfigureerd: priority 10: hosted AV oplossing en priority 20: public FQDN van onze exchange server
• SPF record gepubliceerd in de publieke DNS en de interne DNS

Toch krijgen we regelmatig SPAM berichten binnen. Na analyse van de headers blijken deze rechtstreeks naar de Exchange server gestuurd te zijn en met als (fake) afzender steeds een geldig adres binnen het eigen authorative domein.

Wat me opvalt is dat Exchange hiervoor geen TXT DNS lookup doet naar DNS en dus steeds dit geeft:

X-MS-Exchange-Organization-SenderIdResult: None
Received-SPF: None (server.voorbeeld.be: [e-mail] does not designate permitted sender hosts)

Desondanks bestaat er wel degelijk een SPF record in de DNS server die Exchange gebruikt. Wanneer ik deze SPF lookup test via NS lookup geeft deze het correcte resultaat. Via Wireshark zie ik RBL DNS lookups bij het ontvangen van een dergelijke mail, maar geen TXT lookup. Bij andere mails, ontvangen met een afzender in een non-authorative domein, zie ik wél een lookup naar de TXT records.

Ik kan er verder niets over terugvinden. Iemand een idee waarom Exchange hiervoor geen Sender ID verificatie doet?

[Predator]

Kan je toch de output eens posten van:

code:

nslookup -type=TXT jouwdomein.be

Maar ik vind toch dat je hier SPF checks voor het verkeerde doel gebruikt.
Ik drop altijd expliciet interne maildomeinen als afzenders op security mailrelays voor inkomende email.

Tenzij er een goede reden voor zou zijn is het nergens voor nodig dat je jouw eigen maildomein als afzender moet toelaten op een externe inkomende mailconnecter.
Je hoeft daar ook geen DNS request voor te doen dan (spaart weer een DNS lookup uit ook).

Werkt de sender-ID wel voor andere e-mails eigenlijk (voor andere externe domainen) ?

Ik zie ook dat je eerste MX record een hosted AV oplossing is, en dan je eigen exchange.
Stuurt die hosted oplossing ook dan naar diezelfde exchange zijn externe SMTP connector ?
Dan kan je wel problemen krijgen als je SPF checks gaat doen (ofwel heb je die gewhitelist).
Maar dan heeft het ook weinig nut van die SPF check nog te doen.

Persoonlijk vind ik dat soort oplossingen ook geen goed idee.
Ik zie heel vaak dat onze backup mailrelay ook massa's SPAM krijgt. Niettegenstaande dat die een lagere prioriteit dan de primary. Veel spam bots sturen bewust naar de alle MX records of naar de laagste priorititeit.

Alle SMTP relays in MX records moeten hetzelfde niveau van SPAM filtering hebben anders zit je met een zwakke schakel.

[Kabouterplop01]

hoe ziet je SPF record eruit?
vertaal het ip adres bijv naar <ext ip adres> en <int ip adres> als je die optie gebruikt...
Wat voor type SPF record is het ? 1 of 2?. Staat het SPF record ook bij je provider?

edit: ik kan er niets aan doen, maar het stoort me: het is Authoritative

[ Voor 16% gewijzigd door Kabouterplop01 op 05-12-2009 18:41 ]

[Robbeke]

Excuses voor de late reply, ik moest één en ander nakijken om correct te kunnen antwoorden en tijd is momenteel beperkt.

Predator schreef op zaterdag 05 december 2009 @ 17:12:
Kan je toch de output eens posten van:

code:

nslookup -type=TXT jouwdomein.be

We hebben split DNS dus deze is de lookup op de Exchange server en de interne DNS.

domein.be.domein.be text =

"spf2.0/pra mx ip4:AA.AA.AA.AA ip4:BB.BB.BB.BB ip4:CC.CC.CC.CC/19
ip4:DD.DD.DD.DD/27 a:FQDN1.hosted.antivirus.com a:FQDN2.hosted.antivirus.com a:FQDN3.hosted.antivirus.com a:FQDN4.hosted.antivirus.com a:hostname.domein.be -all"

AA.AA.AA.AA = IP externe webserver
BB.BB.BB.BB = public IP Exchange server
CC.CC.CC.CC/19 = subnet van provider voor zijn smtp servers. deze gebruiken wij uitgaand als relay.
DD.DD.DD.DD/27 = subnet van hosted AV
a:FQDN1-4.hosted.antivirus.com = hosted antivirus
a:hostname.domein.be = FQDN van exchange server (deze staat niet in public SPF. Public DNS = enkel public IP)

Extern gebruiken we enkel een spf2.0 record, zonder pra synthax. Conform http://www.openspf.org/ standaard. Voor de interne heb ik gebruik gemaakt van de Microsoft sender id wizard. Wat is nu eigenlijk de beste oplossing want beide schijnen niet helemaal compatibel te zijn. Beide registreren in DNS?

Predator schreef op zaterdag 05 december 2009 @ 17:12:
Maar ik vind toch dat je hier SPF checks voor het verkeerde doel gebruikt.
Ik drop altijd expliciet interne maildomeinen als afzenders op security mailrelays voor inkomende email.
Tenzij er een goede reden voor zou zijn is het nergens voor nodig dat je jouw eigen maildomein als afzender moet toelaten op een externe inkomende mailconnecter.
Je hoeft daar ook geen DNS request voor te doen dan (spaart weer een DNS lookup uit ook).

Die is er wel degelijk. Extern hebben we een webserver met onze website en hier worden e-mails verzonden bij inschrijvingen of bestellingen. Deze server staat al in onze Allowed IP's maar zoals je op Technet in de flowchart "Understanding Anti-Spam & Antivirus Mail Flow" kan terugvinden zal het domein blokkeren tot gevolg hebben dat deze mails niet meer toekomen, ondanks whitelisting.

Predator schreef op zaterdag 05 december 2009 @ 17:12:
Werkt de sender-ID wel voor andere e-mails eigenlijk (voor andere externe domainen) ?

Ja. Via Wireshark zie ik voor elk non-authoritative domain een dns lookup.

Predator schreef op zaterdag 05 december 2009 @ 17:12:
Ik zie ook dat je eerste MX record een hosted AV oplossing is, en dan je eigen exchange.
Stuurt die hosted oplossing ook dan naar diezelfde exchange zijn externe SMTP connector ?
Dan kan je wel problemen krijgen als je SPF checks gaat doen (ofwel heb je die gewhitelist).
Maar dan heeft het ook weinig nut van die SPF check nog te doen.

Whitelisted inderdaad. En het heeft wel degelijk zin vermits onze server als secondary MX record geconfigureerd staat. Hierdoor krijgt hij ook rechtstreeks (spam) mail binnen waarvoor SPF checks handig zijn. Zou een oplossing zijn een aparte SMTP connector aanmaken die op één of andere manier enkel connecties accepteert van onze hosted Antivirus & webserver (op basis van IP of subnet?). Hoe zorg ik dan dat de combinatie IP:port uniek is?

Predator schreef op zaterdag 05 december 2009 @ 17:12:
Persoonlijk vind ik dat soort oplossingen ook geen goed idee.
Ik zie heel vaak dat onze backup mailrelay ook massa's SPAM krijgt. Niettegenstaande dat die een lagere prioriteit dan de primary. Veel spam bots sturen bewust naar de alle MX records of naar de laagste priorititeit.
Alle SMTP relays in MX records moeten hetzelfde niveau van SPAM filtering hebben anders zit je met een zwakke schakel.

Dat is momenteel ook zo, enkel is de zwakke schakel email verzonden van authoritative domeinen naar onze server. Hier lijkt Exchange zélf minder controle op uit te voeren, voorbeeld hiervan is mijn vraag dat Exchange blijkbaar geen lookup doet voor eigen domeinen.

[ Voor 3% gewijzigd door Robbeke op 13-12-2009 11:27 ]

[Predator]

Robbeke schreef op zondag 13 december 2009 @ 11:23:
.....

Dat ziet er ok uit, maar uit je antwoord verder is dit ook niet meer relevant voor je probleem.
Je ziet gewoon geen DNS lookup dus het probleem is niet je TXT record.

Die is er wel degelijk. Extern hebben we een webserver met onze website en hier worden e-mails verzonden bij inschrijvingen of bestellingen. Deze server staat al in onze Allowed IP's maar zoals je op Technet in de flowchart "Understanding Anti-Spam & Antivirus Mail Flow" kan terugvinden zal het domein blokkeren tot gevolg hebben dat deze mails niet meer toekomen, ondanks whitelisting.

Simpele oplossing, neem een andere domeinnaam voor de mails van je gehoste webserver.

Maar als je niets kan whitelisten kom je inderdaad weer in de problemen met de blocked domains...

Ik kan me trouwens niet voorstellen dat die flowchart correct is, want dan gebeurd er namelijk altijd een SPF lookup, en dat is duidelijk niet het geval.
Ik blijf erbij dat Exchange die mail als intern beschouwd en daarom geen SPF check doet.

Ik ben geen grote fan van Exchange als security mailrelay. Als ik die flowchart zie dan wordt dat alleen maar bevestigd.

Whitelisted inderdaad. En het heeft wel degelijk zin vermits onze server als secondary MX record geconfigureerd staat. Hierdoor krijgt hij ook rechtstreeks (spam) mail binnen waarvoor SPF checks handig zijn. Zou een oplossing zijn een aparte SMTP connector aanmaken die op één of andere manier enkel connecties accepteert van onze hosted Antivirus & webserver (op basis van IP of subnet?). Hoe zorg ik dan dat de combinatie IP:port uniek is?

Dat gaat weinig uitmaken.

Dat is momenteel ook zo, enkel is de zwakke schakel email verzonden van authoritative domeinen naar onze server. Hier lijkt Exchange zélf minder controle op uit te voeren, voorbeeld hiervan is mijn vraag dat Exchange blijkbaar geen lookup doet voor eigen domeinen.

Daar ben ik het niet mee eens.
Jouw Exchange blijft single point of failure, dus ik zie het voordeel niet van die hosted AV/SPAM relay niet, tenzij als die betere resultaten haalt. Maar dan kom ik terug op mijn opmerking van de zwakkere backup MX.

[Kabouterplop01]

spammers gebruiken meestal het 2e mx record om naartoe te spammen! beter lijkt me uw hosted AV als uw 2e mx record. (Als je snapt wat ik bedoel) In theorie kunt u nu al de mail die rechtstreeks op de mailmachine binnenkomt (dus niet vanaf je mailrelays) droppen.
Het lijkt me dat de mail eerst door de av oplossing wordt gestuurd (RR DNS loadbalanced) door de relays heen naar u.
hmm lastig verhaal... Ik denk dat er dan ook eerst een oorzaak moet worden geonden, voor het feit dat wanneer er zo'n vervelend gespoofed mailtje binnenkomt er geen SPF record wordt gelezen, of eigenlijk helemaal geen lookup; hier hoort gewoon een reverse lookup voldoende te zijn. deze valt niet binnen het domein of de perimeter ip adressen. En zo lijkt het SPF record er ook uit te zien. Alleen de ip adressen van binnen en de webservert en de relays mogen vanuit uw naam sturen.

een totaal ander beeld krijgt u natuurlijk als de provider een ook een inbound mailrelay dienst heeft.
dan komt uw mx record niet meer om de hoek kijken ...dan heeft uw SPF record meer toegevoegde waarde; alles wat rechtstreeks binnekomt en dus niet inbound vanaf de mailrelay kun je dan droppen; bovendien scheelt dat weer whitelisten (nl alleen de ip adressen/fqdn's van de inbound mailrelays en de webserver zijn dan trusted)
zou mooi zijn als je provider zoiets heeft..

[ Voor 38% gewijzigd door Kabouterplop01 op 15-12-2009 23:15 ]