Likes: 0
Mensen van Tiscali/Wanadoo/Yucom.be,
Kunnen jullie a.u.b. bevestigen of de IP adressen vanwaar jullie
(incoming) SMTP servers de call-back doen, ook in 62.235.13/24 liggen ?
Tiscali/Wanadoo/Yucom.be mail system administrators,
Please confirm whether the incoming SMTP servers that perform the
call-back, have IP addresses in the 62.235.13/24 prefix.
Dank u,
Thank you,
Eric.
Eric Luyten wrote:
>
> Mensen van Tiscali/Wanadoo/Yucom.be,
>
> Kunnen jullie a.u.b. bevestigen of de IP adressen vanwaar jullie
> (incoming) SMTP servers de call-back doen, ook in 62.235.13/24 liggen ?
Huh? Wat bedoel je hiermee? Een call-back is een telefoongesprek, een
SMTP server is een mailserver.
A record and CNAME:
smtp.tiscali.be. 0 IN A 62.235.13.210
smtp.tiscali.be. 0 IN A 62.235.13.211
smtp.tiscali.be. 0 IN A 62.235.13.171
Als je wil weten of ze intern op de support de zelfde server gebruiken,
kijk dan in de headers van de mail.
--
houghi
houghi <houghi@houghi.org.invalid> wrote:
> Eric Luyten wrote:
>>
>> Mensen van Tiscali/Wanadoo/Yucom.be,
>>
>> Kunnen jullie a.u.b. bevestigen of de IP adressen vanwaar jullie
>> (incoming) SMTP servers de call-back doen, ook in 62.235.13/24 liggen ?
> Huh? Wat bedoel je hiermee? Een call-back is een telefoongesprek,
Onder "call-back" wordt in deze context ook de (hoogst controversiele)
techniek bedoeld waarbij de server die een mailbericht aangeboden wordt,
een SMTP-verbinding "terug" maakt naar de MX voor de domeinnaam van het
in de aangeboden mail envelope aanwezige afzenderadres. Vals of juist,
en daar nijpt 'm precies het schoentje. Indien het Yucom/Tiscali/Wanadoo
conglomeraat per dag honderdduizend spams aangeboden krijgt met *onze*
domeinadressen als (valse) afzender, dan zijn wij wel lekker de pineut.
> een SMTP server is een mailserver.
> A record and CNAME:
> smtp.tiscali.be. 0 IN A 62.235.13.210
> smtp.tiscali.be. 0 IN A 62.235.13.211
> smtp.tiscali.be. 0 IN A 62.235.13.171
> Als je wil weten of ze intern op de support de zelfde server gebruiken,
> kijk dan in de headers van de mail.
De "call-back" resulteert niet in aflevering van een bericht, men wenst
enkel de SMTP reply code te kennen als zij de "From" van het hen aange-
boden bericht in een "RCPT TO" lijn steken.
Eric.
Eric Luyten wrote:
> De "call-back" resulteert niet in aflevering van een bericht, men wenst
> enkel de SMTP reply code te kennen als zij de "From" van het hen aange-
> boden bericht in een "RCPT TO" lijn steken.
OK. Nu is het duidelijk. Ik neem aan dat het de SMTP servers zijn die de
mail dus ontvangen. (Die van de MX records)
MX record for tiscali.be:
tiscali.be. 1 IN MX 10 mail-in.tiscali.be.
tiscali.be. 1 IN MX 20 mailer.tiscali.be.
All known A records for tiscali.be on ns.tiscalinet.be.
tiscali.be. 0 IN A 62.235.14.236
mail-in.tiscali.be. 0 IN A 62.235.13.191
mail-in.tiscali.be. 0 IN A 62.235.13.190
mail-in.tiscali.be. 0 IN A 62.235.13.189
mail-in.tiscali.be. 0 IN A 62.235.13.192
mailer.tiscali.be. 0 IN A 62.235.13.209
ns2.tiscalinet.be. 3600 IN A 62.235.13.198
ns4.tiscalinet.be. 3600 IN A 62.235.14.4
MX record for euronet.be:
euronet.be. 3600 IN MX 100 vs.tiscali.be.
euronet.be. 3600 IN MX 200 vs-backup.tiscali.be.
(Backup naar de zelfde machine. Werkt ook lekker. :-)
All known A records for euronet.be on ns.euronet.be.
euronet.be. 3600 IN A 195.74.193.78
vs.tiscali.be. 2930 IN A 62.235.13.102
vs-backup.tiscali.be. 23 IN A 62.235.13.102
Ziet er inderdaad uit dat het 62.235.13/24 is, maar dat kan natuurlijk
altijd veranderen zodra ze willen.
--
houghi
houghi wrote:
> Eric Luyten wrote:
>> De "call-back" resulteert niet in aflevering van een bericht, men
>> wenst enkel de SMTP reply code te kennen als zij de "From" van het
>> hen aange- boden bericht in een "RCPT TO" lijn steken.
Met andere woorden, bestaat de verzender van het bericht wel echt? Zo
nee, accepteer de mail niet (100% zeker spam), zo ja, dan hoeft het
geen spam te zijn. Hoezo is dat controversieel? Integendeel lijkt me.
Jammer dat postfix dat nog niet doet, anders zou ik het ook direct
gebruiken.
>
> OK. Nu is het duidelijk. Ik neem aan dat het de SMTP servers zijn die
> de mail dus ontvangen. (Die van de MX records)
>
> MX record for tiscali.be:
> tiscali.be. 1 IN MX 10 mail-in.tiscali.be.
> tiscali.be. 1 IN MX 20 mailer.tiscali.be.
>
> All known A records for tiscali.be on ns.tiscalinet.be.
> tiscali.be. 0 IN A 62.235.14.236
> mail-in.tiscali.be. 0 IN A 62.235.13.191
> mail-in.tiscali.be. 0 IN A 62.235.13.190
> mail-in.tiscali.be. 0 IN A 62.235.13.189
> mail-in.tiscali.be. 0 IN A 62.235.13.192
> mailer.tiscali.be. 0 IN A 62.235.13.209
> ns2.tiscalinet.be. 3600 IN A 62.235.13.198
> ns4.tiscalinet.be. 3600 IN A 62.235.14.4
>
> MX record for euronet.be:
> euronet.be. 3600 IN MX 100 vs.tiscali.be.
> euronet.be. 3600 IN MX 200
> vs-backup.tiscali.be. (Backup naar de zelfde machine. Werkt ook
> lekker. :-)
Hmmm, dan vraag ik me af waar vs voor staat. Vast niet voor verenigde
staten. Misschien voor virtual server? :-) Dan zijn het vast meer
machines... :-)
>
> All known A records for euronet.be on ns.euronet.be.
> euronet.be. 3600 IN A 195.74.193.78
> vs.tiscali.be. 2930 IN A 62.235.13.102
> vs-backup.tiscali.be. 23 IN A 62.235.13.102
>
> Ziet er inderdaad uit dat het 62.235.13/24 is, maar dat kan natuurlijk
> altijd veranderen zodra ze willen.
Goed he, dat dns gedoe. Dan hoef je niets aan de naam te veranderen en
kan je iets zomaar een ander ip adres geven. :-)
--
Remove the obvious part (including the dot) for my email address.
http://www.vanwesten.net for examples of ipf and pf.
erik <erik@geenspam.vanwesten.net> wrote:
> houghi wrote:
>> Eric Luyten wrote:
>>> De "call-back" resulteert niet in aflevering van een bericht, men
>>> wenst enkel de SMTP reply code te kennen als zij de "From" van het
>>> hen aange- boden bericht in een "RCPT TO" lijn steken.
> Met andere woorden, bestaat de verzender van het bericht wel echt? Zo
> nee, accepteer de mail niet (100% zeker spam), zo ja, dan hoeft het
> geen spam te zijn. Hoezo is dat controversieel? Integendeel lijkt me.
Op het eerste gezicht inderdaad een niet-zo-kwaad-idee, tenminste...
als je er vanuitgaat dat slechts een klein deel van de e-mailberichten
rondreist met vervalst afzender-adres.
Op het tweede gezicht : die inkomende SMTP connecties die ik (en vele
anderen) zien binnenkomen, zijn
1) ongevraagd (unsollicited),
2) bulk (tijdens spam-runs krijgen *wij* van
Tiscali/Wanadoo/Yucom de volle laag, en
3) e-mail (want op poort TCP/25)
Eric.
erik <erik@geenspam.vanwesten.net> wrote:
> houghi wrote:
>> Eric Luyten wrote:
>>> De "call-back" resulteert niet in aflevering van een bericht, men
>>> wenst enkel de SMTP reply code te kennen als zij de "From" van het
>>> hen aange- boden bericht in een "RCPT TO" lijn steken.
> Met andere woorden, bestaat de verzender van het bericht wel echt? Zo
> nee, accepteer de mail niet (100% zeker spam), zo ja, dan hoeft het
> geen spam te zijn. Hoezo is dat controversieel? Integendeel lijkt me.
Op het eerste gezicht inderdaad een niet-zo-kwaad-idee, tenminste...
als je er vanuitgaat dat slechts een klein deel van de e-mailberichten
rondreist met vervalst afzender-adres.
Op het tweede gezicht : die inkomende SMTP connecties die ik (en vele
anderen) zie(n) binnenkomen, zijn
1) ongevraagd (unsollicited),
2) bulk (tijdens spam-runs krijgen *wij* van
Tiscali/Wanadoo/Yucom de volle laag) en
3) e-mail (want op poort TCP/25)
Eric.
Eric Luyten wrote:
> erik <erik@geenspam.vanwesten.net> wrote:
>> houghi wrote:
>
>>> Eric Luyten wrote:
>>>> De "call-back" resulteert niet in aflevering van een bericht, men
>>>> wenst enkel de SMTP reply code te kennen als zij de "From" van het
>>>> hen aange- boden bericht in een "RCPT TO" lijn steken.
>
>> Met andere woorden, bestaat de verzender van het bericht wel echt? Zo
>> nee, accepteer de mail niet (100% zeker spam), zo ja, dan hoeft het
>> geen spam te zijn. Hoezo is dat controversieel? Integendeel lijkt me.
>
> Op het eerste gezicht inderdaad een niet-zo-kwaad-idee, tenminste...
> als je er vanuitgaat dat slechts een klein deel van de e-mailberichten
> rondreist met vervalst afzender-adres.
>
> Op het tweede gezicht : die inkomende SMTP connecties die ik (en vele
> anderen) zie(n) binnenkomen, zijn
> 1) ongevraagd (unsollicited),
Nee, want er wordt een sender(!) callback gedaan. Raad eens wie de
sender is?
> 2) bulk (tijdens spam-runs krijgen *wij* van
> Tiscali/Wanadoo/Yucom de volle laag) en
Nee, zie boven. Sterker nog, weet je ook wie de veroorzaker is? Ikke
wel. Zie boven.
> 3) e-mail (want op poort TCP/25)
Nope. Er is geen email want de sessie wordt afgebroken.
En wie denk je dat er meer mail krijgt?
EJ, die toch wel blij is met zijn spamassassin op postfix.
--
Remove the obvious part (including the dot) for my email address.
http://www.vanwesten.net for examples of ipf and pf.
"erik" <erik@geenspam.vanwesten.net> schreef in bericht
news:4043ae9c$0$565$c5fe704e@news6.xs4all.nl...
> > 3) e-mail (want op poort TCP/25)
>
> Nope. Er is geen email want de sessie wordt afgebroken.
Het controversiele systeem belast in het vb vd OP toch extra een
niet betrokken SMTP server:
---citaat--
Onder "call-back" wordt in deze context ook de (hoogst controversiele)
techniek bedoeld waarbij de server die een mailbericht aangeboden wordt,
een SMTP-verbinding "terug" maakt naar de MX voor de domeinnaam van het
in de aangeboden mail envelope aanwezige afzenderadres. Vals of juist,
en daar nijpt 'm precies het schoentje. Indien het Yucom/Tiscali/Wanadoo
conglomeraat per dag honderdduizend spams aangeboden krijgt met *onze*
domeinadressen als (valse) afzender, dan zijn wij wel lekker de pineut.
---
erik wrote:
> Nee, want er wordt een sender(!) callback gedaan. Raad eens wie de
> sender is?
Dat weet niemand. Stel dat een spammer mail verstuurd met een adres als
harry@example.com De mail komt aan bij example.com om te zien of die
gebruiker bestaat. Wie zegt dat de server waar die aankomt dat weet? Die
weet enkel dat example.com bestaat.
>> 2) bulk (tijdens spam-runs krijgen *wij* van
>> Tiscali/Wanadoo/Yucom de volle laag) en
>
> Nee, zie boven. Sterker nog, weet je ook wie de veroorzaker is? Ikke
> wel. Zie boven.
De verstuurder kan heel eenvoudig mijn geldig adres gebruiken om spam te
versturen (wat ook al gebeurd is) en dan heb je een geldige adres. Stel
dat er ettelijke miljoenen spams uitgaan met mijn adres als afzend
adres. Wat er dan gebeurd is dat mijn server down gaat omwille van het
feit of iemand kijkt of het adres bestaat. Het adres bestaat, de spam is
verstuurd en mijn server is down.
>> 3) e-mail (want op poort TCP/25)
>
> Nope. Er is geen email want de sessie wordt afgebroken.
DDOS als het ware. Er wordt een connectie met de server gemaakt. Voor
Tiscali zullen die paar duizen extra verbidningen mischien niet
uitmaken, maar dat is helaas niet voor iedereen zo.
Verder intersseerd het de afzender van spam via een gekaapte server
natuurlijk geen ene moer of spam nu wel echt of niet aankomt. Volgende
keer gebruiken ze een ander afzendadres dat wel werkt.
Mijn mening is dat de enige manier om spam aan te pakken is achter het
geld aan. Helaas moet je daar voor bij de Amerikanen zijn en als je al
ziet hoe ze met de rechtzaak SCO omgaan ...
--
houghi
Stefaan wrote:
>
> "erik" <erik@geenspam.vanwesten.net> schreef in bericht
> news:4043ae9c$0$565$c5fe704e@news6.xs4all.nl...
>> > 3) e-mail (want op poort TCP/25)
>>
>> Nope. Er is geen email want de sessie wordt afgebroken.
>
>
> Het controversiele systeem belast in het vb vd OP toch extra een
> niet betrokken SMTP server:
Dat is nu maar net de vraag. En eerlijk gezegd geloof ik niet in het
verhaal dat een checksessie vanuit <> naar een mailserver een grote
belasting oplevert. Er wordt uitsluitend en alleen naar de reaktie (ja,
adres bestaat, of nee bestaat niet) gekeken. Direkt daarna wordt de
verbinding op een volledig legitieme manier afgebroken. Er wordt met
zekerheid *niet* een mail gestuurd.
Heb je enig idee hoe vaak dat al op mijn domeintjes voorkomt? De load
laat zich omschrijven als 0.00. :-)
Enig idee wat de belasting op mailservers is? Enig idee waar de load
vandaan komt? Hint: kijk eens naar queueing. _Daar_ en nergens anders
zit de load. Zowel voor de processor als voor de disk subsystemen.
[knip citaat wat iedereen terug kan lezen]
Het zou Eric sieren als hij wat meer onderzoek doet naar de werkelijke
belasting *voordat* er uitspraken komen dat het zo'n load geeft. Indien
gewenst wil ik hem daar best bij helpen.
Virus bounces, en mailtjes dat een (foutieve) afzender een virus heeft,
die geven een *heel* *veel* *grotere* load.
EJ
--
Remove the obvious part (including the dot) for my email address.
http://www.vanwesten.net for examples of ipf and pf.
houghi wrote:
> erik wrote:
>> Nee, want er wordt een sender(!) callback gedaan. Raad eens wie de
>> sender is?
>
> Dat weet niemand. Stel dat een spammer mail verstuurd met een adres
> als harry@example.com De mail komt aan bij example.com om te zien of
> die gebruiker bestaat. Wie zegt dat de server waar die aankomt dat
> weet? Die weet enkel dat example.com bestaat.
>
>>> 2) bulk (tijdens spam-runs krijgen *wij* van
>>> Tiscali/Wanadoo/Yucom de volle laag) en
>>
>> Nee, zie boven. Sterker nog, weet je ook wie de veroorzaker is? Ikke
>> wel. Zie boven.
>
> De verstuurder kan heel eenvoudig mijn geldig adres gebruiken om spam
> te versturen (wat ook al gebeurd is) en dan heb je een geldige adres.
> Stel dat er ettelijke miljoenen spams uitgaan met mijn adres als
> afzend adres. Wat er dan gebeurd is dat mijn server down gaat omwille
> van het feit of iemand kijkt of het adres bestaat. Het adres bestaat,
> de spam is verstuurd en mijn server is down.
En de spam is _niet_ aangekomen.
>
>>> 3) e-mail (want op poort TCP/25)
>>
>> Nope. Er is geen email want de sessie wordt afgebroken.
> DDOS als het ware. Er wordt een connectie met de server gemaakt. Voor
> Tiscali zullen die paar duizen extra verbidningen mischien niet
> uitmaken, maar dat is helaas niet voor iedereen zo.
En daar geloof ik dus gewoon helemaal niets van. Niet zo lang geleden
70000 bounces via een dial up verbinding binnen gekregen. De load? Te
verwaarlozen.
>
> Verder intersseerd het de afzender van spam via een gekaapte server
> natuurlijk geen ene moer of spam nu wel echt of niet aankomt. Volgende
> keer gebruiken ze een ander afzendadres dat wel werkt.
De moraal van het verhaal: hou je servers dicht. De onbenulligheid
waarmee gereageerd wordt als je een relayende server meldt is
veelzeggend.
>
> Mijn mening is dat de enige manier om spam aan te pakken is achter het
> geld aan. Helaas moet je daar voor bij de Amerikanen zijn en als je al
> ziet hoe ze met de rechtzaak SCO omgaan ...
Helaas. Die methode is effectief de nek omgedraaid.
EJ
--
Remove the obvious part (including the dot) for my email address.
http://www.vanwesten.net for examples of ipf and pf.
erik wrote:
>> Verder intersseerd het de afzender van spam via een gekaapte server
>> natuurlijk geen ene moer of spam nu wel echt of niet aankomt. Volgende
>> keer gebruiken ze een ander afzendadres dat wel werkt.
>
> De moraal van het verhaal: hou je servers dicht. De onbenulligheid
> waarmee gereageerd wordt als je een relayende server meldt is
> veelzeggend.
Tuurlijk moet je je servers dichthouden.
>
>>
>> Mijn mening is dat de enige manier om spam aan te pakken is achter het
>> geld aan. Helaas moet je daar voor bij de Amerikanen zijn en als je al
>> ziet hoe ze met de rechtzaak SCO omgaan ...
>
> Helaas. Die methode is effectief de nek omgedraaid.
Yep en dat al een paar jaar geleden. Het begon fout te gaan in, ik dacht
1485 of zo toen de een of andere Italiaan geld ging zoeken om naar Inda
te gaan. In 1492 dacht hij het gevonden te hebben.
--
houghi
Quote