exchange mailen via ISP

[shaowoo]

ik kom er niet meer uit .. na 3 uurtjes googlen en 2 dagen server configuraties aanpassen, geef ik het op ,hopelijk hebben jullie ideeen.
situatie: ik heb zojuist thuis een netwerk opgebouwd waaronder een Exchange 2k3 (met sp2).
Ik wil email via de smtp server van mijn provider versturen (telebyte), ik heb een adsl abo bij telebyte (vandaar).

ik heb dus een connector aangemaakt (waarbij mail.telebyte.nl als smart host heb ingevuld). Probeer ik een mailtje te versturen dan krijg ik dit:

[e-mail] on 11/11/2006 8:35 AM
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<[mijn domein naam] #5.7.1 smtp;550 5.7.1 <[e-mail]>... Relaying denied. IP name possibly forged [ip adres]>
[mijn domein] naam het ik laten aanmaken en naar mijn adsl [ip adres] laten wijzen.

Ik dus ..huh? met outlook kan ik gewoon mail versturen. Ik dus met telnet mail.telebyte.nl 25 en met de hand een email naar [e-mail] opmaken, deze kan ik zonder problemen versturen ?? schiet mij maar lek..

Ik heb geen antivirus of andere rare dingen op mijn exch server geinstalleerd.. heb al gekeken bij microsoft knowledge base (http://www.microsoft.com/...fo/tips/Trblsht_Tip01.asp)

[Bergen]

Relaying denied.

Zou genoeg moeten zeggen. Google maar eens op die 2 woordjes. Ik denk dat je nog moet authenticaten. Outlook maakt afaik gebruik van het feit dat er eerst mail wordt opgehaald (waarbij je al authenticate) voordat hij uitgande mails verstuurt. POP-before-SMTP heet dat. Bij een smarthost is dat geen optie, dus je moet authenticaten.

Is het alleen om even te prutsen in een thuisnetwerk of is het een permanente mailserver? Dan kun je er natuurlijk voor kiezen om gewoon geen smarthost te gebruiken maar er een 'echte' mailserver van te maken.

[ Voor 37% gewijzigd door Bergen op 11-11-2006 01:04 ]

[shaowoo]

maar vanuit een telnet sessie hoef ik niet te authenticeren, en vanuit outlook heb ik nergens een account ingevoerd voor mail.telebyte. Ik ontvang mijn email vanaf een ander site en verstuur mijn email via telebyte.

het is eigenlijk deel hobby en deels echte mailserver .. je bedoelt waarschijnlijk een mx record aanmaken? ...tsja...

Dit zou toch gewoon moeten werken...

[ Voor 27% gewijzigd door shaowoo op 11-11-2006 01:06 ]

[DaRealRenzel]

Zoals hierboven al gezegd, stel geen smarthost in als je die niet hebt, en voila, je mailserver zal direct aan de aflever-server connecten en afleveren.

Of Telebyte moet uitgaande traffic op SMTP blocken, maar in dat geval zouden ze wel een smarthost opgesteld hebben....


Suc6

[Bergen]

shaowoo schreef op zaterdag 11 november 2006 @ 01:05:
je bedoelt waarschijnlijk een mx record aanmaken? ...tsja...

Ja, waarom niet? Nouja ik zou beide setups proberen, daar leer je alleen maar van.

Voor SMTP-authentication heb je onder Linux TLS-dingetjes (Transport Layer Security), heb je dat in Exchange ook?

Heb je bij die telnetsessie misschien alleen naar jezelf geprobeerd te mailen? Zo ja, probeer eens naar een ander domein te mailen.

[ Voor 15% gewijzigd door Bergen op 11-11-2006 01:30 ]

[DaRealRenzel]

Alleen voor inkomende mail heb je een MX record nodig, voor uitgaande niet.

Voor authenticatie is TLS niet nodig. Alhoewel Exchange dit ook ondersteunt. Standaard SMTP authenticatie werkt ook (sessie-based).

ALs je ook inkomende mail wilt, zul je op een extern gehost DNS record een MX record toe moeten laten voegen. Als je alleen uitgaande mail wilt, zorg dan dat je netwerk goed loopt (internet toegang okee ? ) dan gaat het bijna altijd goed.

[alt-92]

DaRealRenzel schreef op zaterdag 11 november 2006 @ 01:46:
Als je alleen uitgaande mail wilt, zorg dan dat je netwerk goed loopt (internet toegang okee ? ) dan gaat het bijna altijd goed.

Bijna altijd inderdaad, totdat er ergens een (reverse)-DNS check wordt uitgevoerd en blijkt dat je uit een customer IP range mailt.
Dan wil het nog wel eens mis gaan bij gebrek aan reverse DNS entry bijvoorbeeld.

Om te kunnen zien wie er wat blocked moet je wel de volledige headers hebben zodat je de route kan volgen.

[shaowoo]

Ik heb op een gegeven moment, de smart host entry (bij de connector) leeg gelaten en via de DNS email laten versturen. Dit gaat ook niet,...uit de smtp log wordt ik ook niet echt wijzer.

"Om te kunnen zien wie er wat blocked moet je wel de volledige headers hebben zodat je de route kan volgen."

Is dit iets wat ik via smtp log moet kunnen opmaken ? Of via een ander logging?

Dat van die Mx wist ik niet,..dus om mail te kunnen versturen hoef ik geen mx record te hebben. Hmm dat maakt het allemaal helemaal vaag..
1) email via telnet poort 25 kan (naar een email acnt buiten mijn domein ,[e-mail])
->ik kan relayen via de mail server van telebyte. .. of is dit een foute conclusie?
Gaat exchange er anders mee om?..uit de smtp log gaat het totdat de rcpt ingevoerd wordt..(het helo command, SEND TO: .. krijgen de 'ok' melding).
2) het direct mailen vanuit exchange gaat ook niet,.terwijl ik via een nslookup de mx record kan opvragen. Dus een fout in resolvement gaat niet goed.. maar kan het zijn dat de ip adres twee 'namen' heeft. Namelijk eentje vanmijn eigen domein en eentje van de provider (adsl naam)??


brrr ik wordt er helemaal kriegelig van.. het vage vermoeden bekruipt mij dat misschien telebyte 'iets' filterd ?... heeft iemand zo'n constructie bij andere providers?

[smesjz]

Ik ben geen Exchange guru maar "550 Relaying denied. IP name possibly forged " is hier terug te vinden:
http://www.sendmail.org/~...gdenied.html#RELDENFORGED

Kan je de volledige logs laten zien? Wat is de HELO die Exchange gebruikt? 'jouwdomein.local' ofzo?

[shaowoo]

- - 220+mailhub2.telebyte.nl+ESMTP+Customer+MailExchange 0 0 52 0 3453 SMTP
EHLO - main.itquest.nl 0 0 4 0 3453 SMTP - - - -
- - 250-mailhub2.telebyte.nl+Hello+213-211-186-186.dyn.babyxl.dsl.telebyte.nl+[213.211.186.186]+(may+be+forged),+pleased+to+meet+you 0 0 128 0 3469 SMTP - - - -
MAIL - FROM:<[e-mail]>+SIZE=1155 0 0 4 0 3484 SMTP - - - -
- - 250+2.1.0+<[e-mail]>...+Sender+ok 0 0 54 0 8516 SMTP - - - -
RCPT - TO:<[e-mail]> 0 0 4 0 8516 SMTP - - - -
- - 550+5.7.1+<[e-mail]>...+Relaying+denied.+IP+name+possibly+forged+[213.211.186.186] 0 0 93 0 8609 SMTP - - - -
RSET - - 0 0 4 0 8609 SMTP - - - -

------------------------------------------------------------------------------
ik heb een eigen subdomein,.. blijkbaar lukt de gehele opstelling niet omdat de reverse lookup niet klopt ("ip name possibly forged"). Maar het rare is als ik het geheel gewoon via telnet doe, dan dat het wel kan ? Dat is niet consequent....

:edit
Nou breekt mijn klomp.. heb net een freeware mailproggie gedownl (mecury) en hiermee kan ik wel email versturen zonder problemen (mail via mail.telebyte.nl). Zou het probleem dan toch iets van Exchange zijn ? Zou 'ie misschien de logfile parsen en dan een error geven als de "ip name possible forged" ziet?

pff even de eventlogging aangezet en het volgende zie ik dan:
/quote
This is an SMTP protocol error log for virtual server ID 1, connection #3. The remote host "213.211.129.99", responded to the SMTP command "rcpt" with "550 5.7.1 <[e-mail]>... Relaying denied. IP name possibly forged [213.211.186.186] ". The full command sent was "RCPT TO:<[e-mail]> ". This will probably cause the connection to fail.
/end quote

even zoeken op de eventid (7004) ..
edit2:
Als ik nu handmatig telnet naar 213.211.129.99 (poort 25) dan lukt het me niet om email te versturen, het rare is als ik via telnet mail.telebyte doe dat ik dan op een ander adres uitkomt. Het lijkt alsof Exchange dan naar een ander mailserver gestuurd wordt.. vermoed dat de probleem gevonden is.. denk ik..

bingo: exchange komt inderdaad op een ander smtp server,. hier zie ik dan:
ESMTP Customer MailExchange
als ik gewoon naar de reguliere smtp server ga,..dan zie ik:
ESMTP Sendmail 8.13.1/8.13.1

hmm..ik vraag me ik de exchange server dan met de 'sendmail' kan laten praten..

[ Voor 41% gewijzigd door shaowoo op 12-11-2006 14:10 ]

[smesjz]

Dit is ook vragen om problemen:

[smesjz@chewbacca:/]# host main.itquest.nl
main.itquest.nl has address 213.211.186.186

[smesjz@chewbacca:/]# host -t mx main.itquest.nl
main.itquest.nl has no MX record

[smesjz@chewbacca:/]# host -t mx itquest.nl
itquest.nl mail is handled by 0 itquest.nl.

[smesjz@chewbacca:/]# host itquest.nl
itquest.nl has address 193.138.204.235
itquest.nl mail is handled by 0 itquest.nl

Ik zou gaan voor een MX record met prio 10, bijv. mail.itquest.nl
Dat A record verwijst dus weer naar 193.138.204.235

Je HELOt trouwens niet met je FQDN (213-211-186-186.dyn.babyxl.dsl.telebyte.nl) maar met 'main.itquest.nl'.

Fix dat eerst eens

[alt-92]

Krijg je niet gefixed want telebyte gaat echt geen reverse DNS entry voor itquest.nl aanmaken in hun DNS zonefile voor dynamic DSL ip adressen

[Fallout]

Ik heb dit topic heel vluchtig doorgelezen, dus forgive me if i am wrong...

Volgens mij mag je niet bij je eigen server relayen.
Is dit niet gewoon een kwestie dat je je eigen subnet even toevoegt aan het tabje voor granting relay?? System Manager » SMTP » Access » Relay
Dus, als je nu OWA gebruikt, mag je waarschijnlijk wel gewoon mailen.

[alt-92]

Fallout schreef op zondag 12 november 2006 @ 17:53:
Ik heb dit topic heel vluchtig doorgelezen, dus forgive me if i am wrong...

Volgens mij mag je niet bij je eigen server relayen.

Heeft er niks mee te maken want de relay meldingen komen van telebyte.nl mailservers.
Dan ben je per definitie al voorbij je eigen maildoos

[Fallout]

OK, dat werd me niet zo snel duilijk in de topic start..


Zal dit helpen???
http://www.experts-exchan.../Sendmail/Q_21099793.html

[alt-92]

Nope.

Misschien doe je er toch verstandiger aan het topic dan wel goed door te lezen?

[ Voor 89% gewijzigd door alt-92 op 12-11-2006 18:56 ]

[smesjz]

Als ik zelf telnet naar mail.telebyte.nl of mailhub2.telebyte.nl EN ik HELO met 'smesjz' dan krijg ik gewoon Relaying denied i.p.v. possible forged o.i.d. er bij.

Ik gebruik dan de voorbeelden van de TS:

code:

220 mailhub2.telebyte.nl ESMTP Customer MailExchange
helo smesjz
250 mailhub2.telebyte.nl Hello chewbacca.eendomein.nl [77.223.14.143], pleased to meet you
mail from: <[e-mail]>
250 2.1.0 <[e-mail]>... Sender ok
rcpt to: <[e-mail]>
550 5.7.1 <[e-mail]>... Relaying denied

Dus het probleem ligt het bij telebyte zo te zien:

code:

[smesjz@chewbacca:/]# host 213.211.186.186
186.186.211.213.in-addr.arpa domain name pointer 213-211-186-186.dyn.babyxl.dsl.telebyte.nl.
[smesjz@chewbacca:/]# host 213-211-186-186.dyn.babyxl.dsl.telebyte.nl
Host 213-211-186-186.dyn.babyxl.dsl.telebyte.nl not found: 3(NXDOMAIN)

Dit is iets wat alleen Telebyte kan fixen.

[shaowoo]

Smesjz,..hmm je gaf een goede pointer mbt de HELO statement:
/quote
Je HELOt trouwens niet met je FQDN (213-211-186-186.dyn.babyxl.dsl.telebyte.nl) maar met 'main.itquest.nl'.
/end quote

Ik wilde vanuit mijn exchange server mailtjes kunnen versturen, van wat ik begreep heb ik geen mx record hiervoor nodig. Het ontvangen van mail moet ik inderdaad en mx record nodig, ...

Maar ik kan vanuit exchange met 213-211-186-186.dyn.babyxl.dsl.telebyte.nl HELO'en, ipv mijn domain main.itquest.nl Ik kan me voorstellen dat telebyte niet relayed van IP adressen buiten hun IP range. Vandaar dat je niet kan mailen via hun mail server Smezje.. ik zit bij telebyte en dus inhun IP range.

Dat van 'forged ip' is te verklaren door het volgende:
1) ik helo met main.itquest.nl ,..deze staat in dns geregistreerd on mijn adsl ip adres .213.x.y.x
2) vervolgens doet hij een reverse lookup van 213.x.y.x en hier komt daneen ander uit nml 213-211-186-186.dyn.babyxl.dsl.telebyte.nl

Op basis hiervan wordt vanuit de de mailserver mailhub2.telebyte.nl niet gerelayed. Echter vanaf mail.telebyte.nl wordt dit blijkbaar toegestaan.

Maar smesjz..ik ga jouw opmerking eens proberen. Ik ga HELO'n met 213-211-186-186.dyn.babyxl.dsl.telebyte.nl eens kijken of dat werkt...


Update:
zojuist de masqurade domein geprobeerd, helaas dit gaat niet. Ik ga morgen maar eens met telebyte praten,eens kijken of ze hun reverse lookup zone kunnen aanpassen ,dus ipv 213-211-186-186.dyn.babyxl.dsl.telebyte.nl moet deze main.itquest.nl geven,.... zal wel niet denk ik ..


Bedankt mede-tweakers voor het meedenken (vooral smesjz)!!

Maarre mocht iemand nog een brilliante idee hebben..let me know !

Voorlopig ga ik geen gebruik maken van smart host en email via DNS laten routeren,..hoop dat er niet te veel mailserver zijndie zo'n reverse lookup uitvoeren.

[ Voor 18% gewijzigd door shaowoo op 12-11-2006 23:27 ]

[smesjz]

Het PTR record van Telebyte is goed (IP naar hostname) alleen de forward van (hostname naar IP) is door Telebyte niet ingesteld.
De kans is klein dat Telebyte haar PTR ook aanpast, maar hoe dan ook: het resultaat van een IP->hostname lookup moet hetzelfde geven als van hostname->IP. Dat voorkomt dus die forged meldingen.

Iedere mailserver voert een reverse lookup uit. Dus als ik HELO doet met 'smesjz' dan geeft Postfix (en sendmail ook dacht ik) netjes mijn IP->hostname naam weer bij het antwoord.

De vraag is alleen een mailserver doet als er geen match is. Op mijn secundaire MXen gebruik ik de setting reject_unknown_reverse_client_hostname om connecties te weigeren waar geen IP->naam is . Deze setting gebruik ik niet op m'n primaire MX omdat er helaas ook mailservers zijn die legitieme mail afleveren maar geen goede DNS geconfigureerd hebben.

Het is uitermate effectief om spam mee te stoppen, maar het levert teveel false positives op. Dus ik vraag me af of er geen mailservers in het wild er zijn die dit checken. Het gebruik van smarthosts schermt slecht geconfigureerde mailservers netjes af van de buitenwereld, gebruik ze dan ook i.p.v. vanaf je eigen kabelmodem/ADSL zelf mail te versturen.

Voor bij chello.nl/home.nl dwing ik af in mijn configuratie dat ik alleen mail accepteer van de mailservers van die providers en geen directe connecties vanaf zo'n kabelmodem. Misschien wat overdreven, maar het helpt absoluut om spam en virussen terug te dringen.

[Tylen]

Het is toch logisch dat je niet kan relayen.

Ik probeer het makkelijk uitteleggen.

Vanuit het interne netwerk van Telebyte (dus bij jou thuis) mag je alleen mailen met een telebyte adres naar externe. (Tenminste dat lijkt mij ) Dus vanuit jou machine mag je alleen met <naam>@telebyte.nl mailen. (Dit geld alleen voor de SMTP server van Telebyte)

Als je dus een eigen domain thuis hebt draaien moet je het mx record naar huis hebben staan. (inkomend email verkeer) Vervolgens kan je met je eigen SMTP server direct naar buiten mailen. Alleen heb je dan het probleem dat sommige mailservers een reverse DNS check doen en dan zien dat je vanuit een dynamisch ipadres mailt en je mailtje bounchen.

Snappie

Hoe is dit nou op te lossen.

Zorg dat je mag relayen bij een maat die een SMTP server ergens heeft staan in een colo ofzo. Als je beheerder bent van de server op je werk ofzo is het helemaal makkelijk

[shaowoo]

Jeroen

/quote
Vanuit het interne netwerk van Telebyte (dus bij jou thuis) mag je alleen mailen met een telebyte adres naar externe. (Tenminste dat lijkt mij ) Dus vanuit jou machine mag je alleen met <naam>@telebyte.nl mailen. (Dit geld alleen voor de SMTP server van Telebyte)
/end quote

Uhmm,..ik kan wel naar buiten mailen, ik ben dus niet beperkt tot <naam>@telebyte.nl .Zo heb ik dus via simpelweg 'telnet mail.telebyte.nl 25' een emailtje naar mijn hotmail account kunnen sturen (met een ander 'from' adres).

Het kunnen relayen via een bestaande smpt server hmmm ..dat is ook wel een ideetje
Ik heb wel gister een meeltje naar telebyte gestuurd met de medeling of er in de forward lookup zone een ptr aangemaakt kan worden. Ik ben nog steeds van mening dat het hieraan ligt,.. Wanneer forward lookup mislukt,dan kan het aannemelijk zijn dat je aan het spoofen bent en mogelijk hun mailserver misbruikt (voor spam).

[smesjz]

Jeroen_Tielen schreef op dinsdag 14 november 2006 @ 11:19:
Het is toch logisch dat je niet kan relayen.

Ik probeer het makkelijk uitteleggen.

Vanuit het interne netwerk van Telebyte (dus bij jou thuis) mag je alleen mailen met een telebyte adres naar externe. (Tenminste dat lijkt mij ) Dus vanuit jou machine mag je alleen met <naam>@telebyte.nl mailen. (Dit geld alleen voor de SMTP server van Telebyte)

Dat is erg onlogisch en dat maakt Telebyte de enige Nederlandse ADSL provider bij mijn weten die zo'n debiele regel hanteert. Alleen relayen op basis van afzender adres maakt het wel erg gemakkelijk om die mailserver te misbruiken om massa spam te versturen.

Relayen gebeurt normaal op IP-range of SMTP-Auth (pop-before-smtp zie je nog maar zelden), dus waar je dat verhaal haalt van relay op basis van afzender-adres is mij onduidelijk.

Als je dus een eigen domain thuis hebt draaien moet je het mx record naar huis hebben staan. (inkomend email verkeer) Vervolgens kan je met je eigen SMTP server direct naar buiten mailen. Alleen heb je dan het probleem dat sommige mailservers een reverse DNS check doen en dan zien dat je vanuit een dynamisch ipadres mailt en je mailtje bounchen.

Snappie

Bouncen is iets anders dan een 5xx of 4xx melding van je SMTP-server hoor.

Bovendien kan je gewoon de mailserver van je provider gebruiken als smarthost. Mits je natuurlijk de juiste SMTP-server pakt van je provider Daarmee voorkom dat je mail wordt geweigerd. Het weigeren van dial-ups zie je steeds meer dus bespaar je gedoe en gebruik een smarthost/relayhost hiervoor. Daar zijn die dingen voor.

En je MX record hoeft helemaal niet dezelfde te zijn als je thuis IP. bSMTP is hier een voorbeeld van. Bovendien je vaak dat outgoing SMTP via andere machine loopt dan incoming.

Hoe is dit nou op te lossen.

Zorg dat je mag relayen bij een maat die een SMTP server ergens heeft staan in een colo ofzo. Als je beheerder bent van de server op je werk ofzo is het helemaal makkelijk

Sorry hoor, dit heeft niks met PNS te maken.Dit soort non-oplossingen schieten niet op. Hij wil gewoon mail via Telebyte versturen en dat kan prima zonder allerlei colo of werk SMTP-servers er bij te betrekken.

[ Voor 4% gewijzigd door smesjz op 14-11-2006 19:53 . Reden: quote tags fix ]

[smesjz]

[b][message=26846039,noline]shaowoo schreef op dinsdag 14 november 2006 @
Ik heb wel gister een meeltje naar telebyte gestuurd met de medeling of er in de forward lookup zone een ptr aangemaakt kan worden.

Sorry hoor, dit slaat werkelijk nergens op. Je maakt geen PTR aan in je forward zone omdat je dat doet in je reverse zone. In bind zijn dit namelijk twee verschillende files en ook andere DNS servers maken dit onderscheid.
Je had je provider ook kunnen mailen met een normaal verzoek i.p.v. allerlei termen door elkaar te mixen

Ik ben nog steeds van mening dat het hieraan ligt,.. Wanneer forward lookup mislukt,dan kan het aannemelijk zijn dat je aan het spoofen bent en mogelijk hun mailserver misbruikt (voor spam).

Een beetje sendmail admin gebruikt dan wel een andere reply code/message aangezien die in Sendmail te configgen zijn:

code:

R$*<@$*$~P>$*   $#error $@ 4.1.8 $: "451 unresolvable host name, check your configuration."

Dat is de default. Bovendien is het nogal lomp om een 5xx terug te geven omdat je dan ook geldige mail definitief weigert. 4xx betekent: tijdelijke error, probeer het later nog eens. 5xx betekent: permanente fout, probeer het niet meer.

Relaying denied is de default reply indien je naar buiten wil mailen en dit mag niet omdat je IP niet in de lijst van Sendmail voorkomt waarvoor ie relayt (mynetworks heet het in Postfix, ben ff de Sendmail naam kwijt) of je bent niet geauthenticated (SMTP-auth indien van toepassing). Het is dus zeer onwaarschijnlijk dat je relaying denied krijgt als het aan je forward/reverse mapping ligt.

[engelbertus]

wij hebben een subdomein bj xs4all. en kunnen zo dus mailen met subdomein.xs4all.nl
we hebben daar dan diverse exhnage accounts aan gekoppld voor de gebruikers op ons werk.
werkt via bSMTP

dit werkt net alsof je gewoon via [e-mail] mail verstuurt, maar dan gewoon met het subdomein gedeelte ertussen, en dan wordt het netjes door xs4all verder gestuurd.
ontvangen werkt ok ideaal. mail die voor ons subdomein binnenkomt wordt geforward naar exchange, is die niet berikbaardan dan wordt het ebwaard tot ie wel beschikbaar is.
tot zover alles goed. problemen krijg je als @home beslist dat [e-mail] geen geldig domein heeft /( het domein is namleijk xs4all.nl en geen subdomein.xs4all.nl) en dan wordt je mailtje dus gebouced.

leuk, en dankje wel @home!

ik vindt het pertinent onjuist dat @home dit doet, omdat een subdomein alleen kan bestaan als je van de domeineigenaar daarvoor toestemming hebt. het is dan een beetje raar dat die eigenaar zelf wel mail mag vesrsturen van @home, en een gebruiker met een subdomein niet.
je kunt dat ook niet faken, want zonder dns waarin het subdomein wordt behandeld/stqaat omschreven bestaat het domein/subdomein niet/

een echt domein via xs4all. en bSMTP is meteen een stuk duurder omdat je dan vast zit aan advanced business mail 1 14,50 per maand, bovenop het business dsl/ dsl abonement, dat meetn 2 tot 3 keer zo duur is als het goedkoopste xs4all abonement voor consumenten, als je een gelijkwaardige snelheid wilt.

dit alles heeft dus te maken met rverse dns, en dat is in jou geval volgens mij ook het geval.

een afzender adres veranderen is iets anders dan een echt exchange account gebruikn.
het from adres van elk mailtje kun je gewoon instellen wat je wilt, desnoods [e-mail], en dan komt het gewoon aan.

[alt-92]

smesjz schreef op dinsdag 14 november 2006 @ 20:05:
Sorry hoor, dit slaat werkelijk nergens op. Je maakt geen PTR aan in je forward zone omdat je dat doet in je reverse zone. In bind zijn dit namelijk twee verschillende files en ook andere DNS servers maken dit onderscheid.
Je had je provider ook kunnen mailen met een normaal verzoek i.p.v. allerlei termen door elkaar te mixen

Er zijn maar heeeeeel erg weinig DSL providers die een PTR in hun reverse zone naar het domain van de klant willen veranderen.

Een beetje sendmail admin gebruikt dan wel een andere reply code/message aangezien die in Sendmail te configgen zijn:

code:

R$*<@$*$~P>$*   $#error $@ 4.1.8 $: "451 unresolvable host name, check your configuration."

Dat is de default. Bovendien is het nogal lomp om een 5xx terug te geven omdat je dan ook geldige mail definitief weigert. 4xx betekent: tijdelijke error, probeer het later nog eens. 5xx betekent: permanente fout, probeer het niet meer.

En dat is ook precies de bedoeling van de beheerder.
Kan niet. Punt. Niet blijven proberen, anders oplossen.

Het is ook geen transient error, maar een opzettelijke config.

Ik denk dat de TS beter uit is met een vraag of er een relay host is bij Telebyte zodat ie met zijndomain.nl kan uitmailen zonder gedoe.
Meestal is die er wel (planet heeft bijvoorbeeld mailrelay.planet.nl daarvoor).

[ Voor 8% gewijzigd door alt-92 op 14-11-2006 20:28 ]

[smesjz]

alt-92 schreef op dinsdag 14 november 2006 @ 20:25:
Er zijn maar heeeeeel erg weinig DSL providers die een PTR in hun reverse zone naar het domain van de klant willen veranderen.

Klopt, maar dat is al eerder gezegd dus dat je hoef je niet nog eens te herhalen. Ik wees TS alleen op een fout in zijn gebruik van de diverse termen.

En dat is ook precies de bedoeling van de beheerder.
Kan niet. Punt. Niet blijven proberen, anders oplossen.

Het is ook geen transient error, maar een opzettelijke config.

Het weigeren van mail vanaf hosts zonder goede DNS (forward, reverse en match) is ook een opzettelijke config. Dus ik snap je punt niet. Standaard wordt geadviseerd om dit met 4xx te doen maar met 5xx kan dus ook zonder problemen. Het is de verantwoordelijkheid van de beheerder.

Het ging er mij om dat het zeer ongebruikelijk is om _ook_ een standaard Relaying denied melding te geven als je iemand weigert ivm slechte DNS configuratie. Dus om aan te geven dat het bijna uit te sluiten is dat de mail van TS daardoor geweigerd wordt i.t.t. wat ie zelf denkt.
[/quote]

[alt-92]

smesjz schreef op dinsdag 14 november 2006 @ 20:45:
Het weigeren van mail vanaf hosts zonder goede DNS (forward, reverse en match) is ook een opzettelijke config. Dus ik snap je punt niet.

Nou, 5.x.x drives the point home om het zo maar eens te zeggen

Je hebt gelijk hoor, maar een 4.x.x gebruiken zou nog wel eens de suggestie kunnen wekken dat je het alleen nu even niet kan doen ipv never nooit niet

Qua relaying denied melding: tja.. het is op zich verklaarbaar om die melding toch in te zetten omdat je geen relayende dozen wil hebben, of het niet over die server wil toestaan.

[smesjz]

alt-92 schreef op dinsdag 14 november 2006 @ 20:52:
[...]

Nou, 5.x.x drives the point home om het zo maar eens te zeggen

Je hebt gelijk hoor, maar een 4.x.x gebruiken zou nog wel eens de suggestie kunnen wekken dat je het alleen nu even niet kan doen ipv never nooit niet

Bij een 5.x.x ga er dus vanuit dat je eigen DNS-servers in /etc/resolv.conf altijd bereikbaar is en werken. Als die DNS-servers opeens moeilijk gaan doen met time-outs enzo ga jij dus legitieme mails permanent weigeren door die 5.x.x omdat je MTA dan geen forward/reverse lookups kan doen.

Bij 4.x.x houd je mogelijk nog er in dat je eigen DNS wel eens kapot zou kunnen gaan en je op die manier mailservers nog een kans geeft. En domme spambots zullen allicht wel afhaken bij een 4.x.x omdat je dan weer extra logica moet inbouwen voor retryen enzo.

Qua relaying denied melding: tja.. het is op zich verklaarbaar om die melding toch in te zetten omdat je geen relayende dozen wil hebben, of het niet over die server wil toestaan.

Als we het toch over 'driving the point home' hebben Het is voor een admin van zelfs sendmail erg makkelijk om die text en error te customizen zodat de melding ook terug slaat op de reden waarom je hem weigert. Als ik alle verschillende 5.x.x meldingen vervang door 'access denied' is het nooit duidelijk voor mij EN de verzendende mailserver waarom ik hem permanent weiger

[alt-92]

smesjz schreef op dinsdag 14 november 2006 @ 20:59:
Bij een 5.x.x ga er dus vanuit dat je eigen DNS-servers in /etc/resolv.conf altijd bereikbaar is en werken.

Bij een beetje professionele ISP is dat ook zo ja.

Bij 4.x.x houd je mogelijk nog er in dat je eigen DNS wel eens kapot zou kunnen gaan en je op die manier mailservers nog een kans geeft. En domme spambots zullen allicht wel afhaken bij een 4.x.x omdat je dan weer extra logica moet inbouwen voor retryen enzo.

Dacht je nou echt dat die de moeite nemen daarvoor? Welnee, die bots gaan gewoon door, 4.x, 5.x of niet.

Als we het toch over 'driving the point home' hebben Het is voor een admin van zelfs sendmail erg makkelijk om die text en error te customizen zodat de melding ook terug slaat op de reden waarom je hem weigert. Als ik alle verschillende 5.x.x meldingen vervang door 'access denied' is het nooit duidelijk voor mij EN de verzendende mailserver waarom ik hem permanent weiger

Daarom kom je ook geen access denied tegen Die relaying melding is echt niet nieuw, en een mede sysadmin snapt echt wel waarom die er staat.

[smesjz]

alt-92 schreef op dinsdag 14 november 2006 @ 21:23:
Dacht je nou echt dat die de moeite nemen daarvoor? Welnee, die bots gaan gewoon door, 4.x, 5.x of niet.

Die bots kiezen voor de makkelijkste weg, ik zie ze niet meer terug komen als ik ze blok met 5xx. Er zitten natuurlijk wel wat hardnekkige bij, maar dat valt reuze mee. Als ik ze al bij weiger bij een HELO (helo myfirstmail.com) komen ze niet vaak terug en gaan ze zelden door.
Idem met DNS blacklists. Ik gebruik gewoon pflogsumm om de logs van Postfix te bekijken.

Die spambots zijn wat dat betreft wel slimmer geworden denk ik, kijk alleen al naar de berichten die ze versturen. Steeds moeilijker voor spamassassin om het er uit te filteren

Daarom kom je ook geen access denied tegen Die relaying melding is echt niet nieuw, en een mede sysadmin snapt echt wel waarom die er staat.

TS dus al niet, en daar gaat het om. Relaying denied slaat terug op relay configuratie (IP, smtp-auth) en niet op wel of niet goede DNS config. Daar is een andere code voor.

[shaowoo]

ik heb inderdaad een term doormekaar gehaalt...:) dank je voor de correctie

ik bel vandaag eens nogmaals naar telebyte.
Misschien niet relevant maar jullie hebben het steeds over 'sendmail' ,maar mijn exchange connecteerd naar:
220 mailhub2.telebyte.nl ESMTP Customer MailExchange

Deze is stricter qua versturen van mail.

Het versturen via 213.211.129.88 (relay2.telebyte.nl ESMTP Sendmail 8.13.1/8.13.1/ etc..) , deze heeft geen probleem..(krijg ook de forged ip melding, maar de mail wordt wel weggestuurd).

[smesjz]

220 mailhub2.telebyte.nl ESMTP Customer MailExchange
help
214-2.0.0 This is sendmail version 8.13.1

gewoon sendmail dus

[shaowoo]

ah...

maar dan snap ik iets toch niet.. waarom kan ik dan met de hand wel email versturen en via exchange weer niet ?

[rdfeij]

alt-92 schreef op zaterdag 11 november 2006 @ 12:13:
[...]

Bijna altijd inderdaad, totdat er ergens een (reverse)-DNS check wordt uitgevoerd en blijkt dat je uit een customer IP range mailt.
Dan wil het nog wel eens mis gaan bij gebrek aan reverse DNS entry bijvoorbeeld.

Om te kunnen zien wie er wat blocked moet je wel de volledige headers hebben zodat je de route kan volgen.

Mail eens niet naar hotmail, hotmail blokkeert veel dingen waarvan inderdaad de reverse dns, etc niet klopt. Omdat je niet athenticate kan het ook zijn dat de smtp server van je provider het boeltje blokkeert omdat hij een onbekende (mogelijk spam) user herkend.

[smesjz]

rdfeij schreef op woensdag 15 november 2006 @ 20:28:
[...]


Mail eens niet naar hotmail, hotmail blokkeert veel dingen waarvan inderdaad de reverse dns, etc niet klopt. Omdat je niet athenticate kan het ook zijn dat de smtp server van je provider het boeltje blokkeert omdat hij een onbekende (mogelijk spam) user herkend.

Ik kan zelf niet testen of het klokt dat hotmail connecties weigert als reverse DNS niet goed geconfigged is. Het lijkt me namelijk erg sterk omdat het nogal een lompe maatregel is die ook legitieme mailservers weigert op die manier.

*edit* Net getest vanaf een host zonder PTR record (Versatel office DSL) en mail naar hotmail.com werd niet geweigerd bij de SMTP sessie.

De hotmail servers hebben inderdaad soms vreemde neigingen, maar zover komt TS al niet.

Maar zowel mailrelay2.telebyte.nl als mail.telebyte.nl ondersteunen bijv. SMTP AUTH via cram-md5, zodat je eens zou kunnen proberen om Exchange je login gegevens te laten mee sturen bij verzenden van mail. Ben benieuwd of dat iets oplevert. Geen idee of Exchange dit snapt hoor.

De TS heeft dus geen problemen met de hotmail servers

[ Voor 6% gewijzigd door smesjz op 15-11-2006 20:56 . Reden: hotmail check ]

[ChaserBoZ_]

smesjz schreef op maandag 13 november 2006 @ 09:14:
Het PTR record van Telebyte is goed (IP naar hostname) alleen de forward van (hostname naar IP) is door Telebyte niet ingesteld.
De kans is klein dat Telebyte haar PTR ook aanpast, maar hoe dan ook: het resultaat van een IP->hostname lookup moet hetzelfde geven als van hostname->IP. Dat voorkomt dus die forged meldingen.

Iedere mailserver voert een reverse lookup uit. Dus als ik HELO doet met 'smesjz' dan geeft Postfix (en sendmail ook dacht ik) netjes mijn IP->hostname naam weer bij het antwoord.

De vraag is alleen een mailserver doet als er geen match is. Op mijn secundaire MXen gebruik ik de setting reject_unknown_reverse_client_hostname om connecties te weigeren waar geen IP->naam is . Deze setting gebruik ik niet op m'n primaire MX omdat er helaas ook mailservers zijn die legitieme mail afleveren maar geen goede DNS geconfigureerd hebben.

Het is uitermate effectief om spam mee te stoppen, maar het levert teveel false positives op. Dus ik vraag me af of er geen mailservers in het wild er zijn die dit checken. Het gebruik van smarthosts schermt slecht geconfigureerde mailservers netjes af van de buitenwereld, gebruik ze dan ook i.p.v. vanaf je eigen kabelmodem/ADSL zelf mail te versturen.

Voor bij chello.nl/home.nl dwing ik af in mijn configuratie dat ik alleen mail accepteer van de mailservers van die providers en geen directe connecties vanaf zo'n kabelmodem. Misschien wat overdreven, maar het helpt absoluut om spam en virussen terug te dringen.

Bij @home kun je je die moeite besparen, poort 25 staat daar standaard dicht.

[smesjz]

ChaserBoZ_ schreef op woensdag 15 november 2006 @ 21:19:
Bij @home kun je je die moeite besparen, poort 25 staat daar standaard dicht.

Jij hebt je de moeite van het lezen bespaard? Het gaat om PNS dus en die hangen in de regel niet aan allerlei particuliere kabel verbindingen...

Het gaat juist om @home kabelmodems die mail _versturen_ naar 'buiten'. Het gaat dus niet om het ontvangen en ik hoopte dat dit al duidelijk genoeg was in mijn post

[ChaserBoZ_]

smesjz schreef op woensdag 15 november 2006 @ 21:39:
[...]


Jij hebt je de moeite van het lezen bespaard? Het gaat om PNS dus en die hangen in de regel niet aan allerlei particuliere kabel verbindingen...

Het gaat juist om @home kabelmodems die mail _versturen_ naar 'buiten'. Het gaat dus niet om het ontvangen en ik hoopte dat dit al duidelijk genoeg was in mijn post

Ow zo, dan las ik het verkeerd

[Asteroid9]

smesjz schreef op woensdag 15 november 2006 @ 21:39:
[...]


Jij hebt je de moeite van het lezen bespaard? Het gaat om PNS dus en die hangen in de regel niet aan allerlei particuliere kabel verbindingen...

Het gaat juist om @home kabelmodems die mail _versturen_ naar 'buiten'. Het gaat dus niet om het ontvangen en ik hoopte dat dit al duidelijk genoeg was in mijn post

Net also alle topics in PNS ook daadwerkelijk over professionele omgevingen gaan...

Ik zie hier toch massa's thuisnetwerk-hobbyprojectjes langs komen!

[smesjz]

Asteroid9 schreef op woensdag 15 november 2006 @ 21:47:
Net also alle topics in PNS ook daadwerkelijk over professionele omgevingen gaan...

Ik zie hier toch massa's thuisnetwerk-hobbyprojectjes langs komen!

Ok, maar dan nog laat mijn post niks aan onduidelijkheid over:

Voor bij chello.nl/home.nl dwing ik af in mijn configuratie dat ik alleen mail accepteer van de mailservers van die providers en geen directe connecties vanaf zo'n kabelmodem.