Tiscali SMTP?

[Andy De Petter]

Blijkbaar heeft Tiscali een beslissing genomen, qua rejecten van spam:

Trying 62.235.13.209...
Connected to mailer.tiscali.be.
Escape character is '^]'.
220 ESMTP Tiscali.be. NO UBE/UCE tolerated.
ehlo blah
250-mailer.tiscali.be Hello blah [195.238.24.200]
250-SIZE 10485760
250-PIPELINING
250 HELP
mail from:<mailer-daemon@vladbert.skynet.be>
250 OK
rcpt to:<mirror@tiscali.be>
451-could not connect to vladbert.skynet.be [195.238.3.12]: Connection refused
451-Could not complete sender verify callout for
451-<mailer-daemon@vladbert.skynet.be>.
451-The mail server(s) for the domain may be temporarily unreachable, or
451-they may be permanently unreachable from this server. In the latter case,
451-you need to change the address or create an MX record for its domain
451-if it is supposed to be generally accessible from the Internet.
451 Talk to your mail administrator for details.


Voor elke mail die ze binnenkrijgen, gaan ze een SMTP connectie openen, naar het MX record van de sender. In veel gevallen (zoals hierboven), zal die server niet antwoorden, en zullen de queues naar Tiscali zich stilaan overal beginnen opbouwen.. Aan de
logs van onze servers te zien, is dit een 2-tal dagen geleden begonnen.

Kan iemand van Tiscali dit bevestigen? En ook bevestigen, of ze zich bewust zijn van de problemen die dit gaat opleveren, voor mail queues bij andere (mail) providers?

-Andy

--
Andy De Petter - http://www.techos.be/andy - naql@gunvobk.or (ROT13)
Expert IT Analyst - Belgacom ANS/NTA/NST - http://www.belgacom.be
"Cogito Ergo Sum - I think, therefore I am."
-- R. Descartes

[Jan Reilink]

Andy De Petter wrote:

> Blijkbaar heeft Tiscali een beslissing genomen, qua rejecten van spam:
>

Blijkbaar niet goed genoeg:

> Trying 62.235.13.209...
> Connected to mailer.tiscali.be.
> Escape character is '^]'.
> 220 ESMTP Tiscali.be. NO UBE/UCE tolerated.
> ehlo blah

(...)

550 geen FQDN / valide DNS naam.

--
Met vriendelijke groet / Best regards,
Jan Reilink

VEVIDA Nederland BV

[frank@openminds.be]

Andy De Petter <andy@brol.be> wrote:
> Blijkbaar heeft Tiscali een beslissing genomen, qua rejecten van spam:

Andy, een beetje onprofessioneel als je hier komt klagen over de
spammaatregelen van een conculega van je, terwijl je zelf niks doet aan
de (ongeveer) grootste professionele spammers in .be.

Voor de deepblueeyes "issue" zou volgens Stefan D een oplossing gezocht
worden om ook maar iets van wettelijke basis te vinden om ze buiten te
kegelen". Blijkbaar bestond/bestaat die oplossing erin:

1) niet meer 'rechtstreeks' op jullie netwerk zitten (good thing)
2) afsluiten van hun skynet mailbox (good thing)

MAAR:

3) ze fake LIR maken
4) liegen over hun peers en transits in hun ripe-objectjes
5) skynet als ENIGE provider gebruiken

Vooral issues 3) en 4) zou jij als echte techo "vrij erg" moeten vinden.

Kortom: pot/ketel/... vul aan.


Vriendelijke groeten,
Frank Louwers

--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

[Glenn Plas]

Die banner hebben we daar al ongeveer een maand of 6 staan trouwens even
lang als onze anti-spam maatregelen. Nog nooit eerder gezien ?

Vind he wel grappig, in je sig staat belgacom en onze incomming spam komt voor 30%
van .... idd Skynet servers ....

Nog vragen verder over hoe het werkt ? Altijd welkom.

Glenn Plas
Senior System Administrator
Tiscali.be NV

On Thu, 16 Oct 2003 10:50:00 +0200, Andy De Petter wrote:

> Blijkbaar heeft Tiscali een beslissing genomen, qua rejecten van spam:
>
> Trying 62.235.13.209...
> Connected to mailer.tiscali.be.
> Escape character is '^]'.
> 220 ESMTP Tiscali.be. NO UBE/UCE tolerated. ehlo blah
> 250-mailer.tiscali.be Hello blah [195.238.24.200] 250-SIZE 10485760
> 250-PIPELINING
> 250 HELP
> mail from:<mailer-daemon@vladbert.skynet.be> 250 OK rcpt
> to:<mirror@tiscali.be>
> 451-could not connect to vladbert.skynet.be [195.238.3.12]: Connection
> refused 451-Could not complete sender verify callout for
> 451-<mailer-daemon@vladbert.skynet.be>. 451-The mail server(s) for the
> domain may be temporarily unreachable, or 451-they may be permanently
> unreachable from this server. In the latter case, 451-you need to change
> the address or create an MX record for its domain 451-if it is supposed
> to be generally accessible from the Internet. 451 Talk to your mail
> administrator for details.
>
>
> Voor elke mail die ze binnenkrijgen, gaan ze een SMTP connectie openen,
> naar het MX record van de sender. In veel gevallen (zoals hierboven),
> zal die server niet antwoorden, en zullen de queues naar Tiscali zich
> stilaan overal beginnen opbouwen.. Aan de logs van onze servers te zien,
> is dit een 2-tal dagen geleden begonnen.
>
> Kan iemand van Tiscali dit bevestigen? En ook bevestigen, of ze zich
> bewust zijn van de problemen die dit gaat opleveren, voor mail queues
> bij andere (mail) providers?
>
> -Andy
>

[Andy De Petter]

Glenn Plas <gplas@be.tiscali.com> wrote:
> Die banner hebben we daar al ongeveer een maand of 6 staan trouwens even
> lang als onze anti-spam maatregelen. Nog nooit eerder gezien ?
>
> Vind he wel grappig, in je sig staat belgacom en onze incomming spam komt voor 30%
> van .... idd Skynet servers ....
>
> Nog vragen verder over hoe het werkt ? Altijd welkom.
>
> Glenn Plas
> Senior System Administrator
> Tiscali.be NV
>
> On Thu, 16 Oct 2003 10:50:00 +0200, Andy De Petter wrote:
>
>> Blijkbaar heeft Tiscali een beslissing genomen, qua rejecten van spam:
>>
>> Trying 62.235.13.209...
>> Connected to mailer.tiscali.be.
>> Escape character is '^]'.
>> 220 ESMTP Tiscali.be. NO UBE/UCE tolerated. ehlo blah
>> 250-mailer.tiscali.be Hello blah [195.238.24.200] 250-SIZE 10485760
>> 250-PIPELINING
>> 250 HELP
>> mail from:<mailer-daemon@vladbert.skynet.be> 250 OK rcpt
>> to:<mirror@tiscali.be>
>> 451-could not connect to vladbert.skynet.be [195.238.3.12]: Connection
>> refused 451-Could not complete sender verify callout for
>> 451-<mailer-daemon@vladbert.skynet.be>. 451-The mail server(s) for the
>> domain may be temporarily unreachable, or 451-they may be permanently
>> unreachable from this server. In the latter case, 451-you need to change
>> the address or create an MX record for its domain 451-if it is supposed
>> to be generally accessible from the Internet. 451 Talk to your mail
>> administrator for details.
>>
>>
>> Voor elke mail die ze binnenkrijgen, gaan ze een SMTP connectie openen,
>> naar het MX record van de sender. In veel gevallen (zoals hierboven),
>> zal die server niet antwoorden, en zullen de queues naar Tiscali zich
>> stilaan overal beginnen opbouwen.. Aan de logs van onze servers te zien,
>> is dit een 2-tal dagen geleden begonnen.
>>
>> Kan iemand van Tiscali dit bevestigen? En ook bevestigen, of ze zich
>> bewust zijn van de problemen die dit gaat opleveren, voor mail queues
>> bij andere (mail) providers?
>>
>> -Andy
>>

Hey Glenn,

Bedankt voor het antwoord.. ik heb je een mailtje gestuurd, met betrekking tot de foutmeldingen en problemen die we momenteel zien, met mail naar jullie toe.

Cya,

-Andy

--
Andy De Petter - http://www.techos.be/andy - naql@gunvobk.or (ROT13)
Expert IT Analyst - Belgacom ANS/NTA/NST - http://www.belgacom.be
"Cogito Ergo Sum - I think, therefore I am."
-- R. Descartes

[Stefaan]

"Andy De Petter" <andy@brol.be> schreef in bericht
news:3f8e86f7$0$30309$ba620e4c@reader2.news.skynet .be...
> Glenn Plas <gplas@be.tiscali.com> wrote:
> > Vind he wel grappig, in je sig staat belgacom en onze incomming spam
komt voor 30%
> > van .... idd Skynet servers ....

Ze hebben de grootste.
Op alle gebieden.

> >
> > Nog vragen verder over hoe het werkt ? Altijd welkom.
> >
> > Glenn Plas
> > Senior System Administrator
> > Tiscali.be NV
> >
> > On Thu, 16 Oct 2003 10:50:00 +0200, Andy De Petter wrote:
>
> Hey Glenn,
>
> Bedankt voor het antwoord.. ik heb je een mailtje gestuurd, met betrekking
tot de foutmeldingen en problemen die we momenteel zien, met mail naar
jullie toe.
>
> Cya,
>
> -Andy



Boeiend, hiermee blijft de doorsnee NG lezer iets minder in het donker
over het waarom als de rejected mail queues
merkbare vertragingen in de gebruikersmailboxen veroorzaken....

Maar ik begrijp niets van deze aanpak:
een Belgacom technicus merkt een alledged SMTP spam reject probleem bij
Tiscali, de concurrentie,
en post het issue 2 dagen later in be.providers - waarna
hij de Senior System Administrator vd concurrentie
hier heel joviaal bedankt voor de reactie.

Ehem.

Hey, Andy, Glenn, my best friends,
hebben jullie geen mail of telefoons om ons deze overlast *vooraf te
besparen?

[xeno]

On Thu, 16 Oct 2003 13:37:19 GMT, "Stefaan" <nomail@email.invalid>
wrote:

>Hey, Andy, Glenn, my best friends,
>hebben jullie geen mail of telefoons om ons deze overlast *vooraf te
>besparen?

BC hecht meer belang aan het feit dat ze concurrenten publiekelijk
kunnen proberen belachelijk maken door te wijzen op (mogelijke)
fouten. Dat BC op zijn beurt zelf blind en doofstom is als er
problemen gemeld worden, dat is dan weer normaal.

De grootste ISP van Belgie maakt immers geen fouten, het zijn enkel de
kleine overblijvende concurrentjes die maar wat zitten 'prutsen'...

[Glenn Plas]

On Thu, 16 Oct 2003 15:37:19 +0200, Stefaan wrote:

> Ze hebben de grootste.
> Op alle gebieden.

op ALLE gebieden ? Zonder natural exercises ?


> Boeiend, hiermee blijft de doorsnee NG lezer iets minder in het donker
> over het waarom als de rejected mail queues merkbare vertragingen in de
> gebruikersmailboxen veroorzaken....

Er zijn geen vertragingen wanneer een mail word geweigerd...

> Maar ik begrijp niets van deze aanpak: een Belgacom technicus merkt een
> alledged SMTP spam reject probleem bij Tiscali, de concurrentie, en post
> het issue 2 dagen later in be.providers - waarna hij de Senior System
> Administrator vd concurrentie hier heel joviaal bedankt voor de
reactie.

Is misschien laat gemeld tussen ons 2 volgens u maar we zijn al meer dan 3 dagen
bezig een case tegen deze persoon (+ blocken sites + blocken
telefoonnummers, + disactivering mailbox). De spam komt niet van Tiscali
of van Skynet alleen. De spam komt van overal, en als wij hen totaal van
ons netwerk halen zullen ze naar andere netwerken overgaan.
Het feit is dat wij niet met elkaar hoeven te praten om een spam probleem
op te lossen/op te merken. Ik heb Belgacom niet nodig om een user te
blocken, om een telefoonnr te blacklisten enzv. En BCM heeft ons ook
niet nodig om hun eigen netwerk te cleanen.

heb ondertussen te weten gekomen dat de mensen die de reclame doorzenden
een firma is die ingehuurd werd door mr Frank Verstraeten. 'die hadden
een lijst vaan 40 000 klanten' <endquote> .... Zucht ....

> Ehem.
>
> Hey, Andy, Glenn, my best friends,
> hebben jullie geen mail of telefoons om ons deze overlast *vooraf te
> besparen?

Wat zou ik beter met een telefoon in mijn hand kunnen doen dan zonder ?
Suggesties welkom.

over welke overlast heb je het eigenlijk ? De spam of de conversatie
hier? Ik zal nog eens mijn tarotkaarten bovenhalen om de volgende
spamming lamers van ons netwerk te gooien die denken dat wij het niet
zullen opmerken.

Glenn

[Jan Reilink]

Stefaan wrote:

[...]
> Boeiend, hiermee blijft de doorsnee NG lezer iets minder in het donker
> over het waarom als de rejected mail queues
> merkbare vertragingen in de gebruikersmailboxen veroorzaken....
>
> Maar ik begrijp niets van deze aanpak:
> een Belgacom technicus merkt een alledged SMTP spam reject probleem bij
> Tiscali, de concurrentie,
> en post het issue 2 dagen later in be.providers - waarna
> hij de Senior System Administrator vd concurrentie
> hier heel joviaal bedankt voor de reactie.
>

(Ik denk...) Andy post zijn vraag hier omdat hij ziet dat Tiscali een 4xx
error afgeeft mocht de SMTP connectie naar het MX record van de verzender
niet tot stand komen. Een 4xx error betekend dat de MTA na $interval weer
probeert de email te versturen, de email blijft zolang in de queue staan.

Door het in de nieuwsgroep te posten vraagt Andy eigenlijk of anderen dit
ook hebben gemerkt, en vraagt (publiekelijk) om uitleg van Tiscali.
Omdat het een vrij grote impact kan hebben op de performance van mailservers
(grote queue, langzame(re) aflevering) is het IMO juist goed dat het hier
gepost / besproken wordt [1].
Beter dan 99% van de "$HOST ligt weer plat" postings :)

> Ehem.
>
> Hey, Andy, Glenn, my best friends,
> hebben jullie geen mail of telefoons om ons deze overlast *vooraf te
> besparen?
>

In Nederand hebben we daar IRC voor ;-))
Spreken we overigens niet liever over "conculega's / collega's" i.p.v.
"concurrenten"? Klinkt wat vriendelijker :P

1. "hier" bij het ontbreken van een geschiktere nieuwsgroep

--
Met vriendelijke groet / Best regards,
Jan Reilink

VEVIDA Nederland BV

[Glenn Plas]

bingo. Niet slecht gedacht.... maar vergeet niet dat al die mails 'die
problemen kunnen veroorzaken' in het omgekeerde situatie geval in ONZE queues zullen
staan (+de bounces die niet kunnen worden afgeleverd). Dan zou de impact
enkel voor ons zijn ... nu is het iedereen die een beetje impacted is.

Dus zo erg kan het niet zijn. Ook meteen een duw in de rug naar anderen
toe om spam/bulk mail niet zomaar door te sturen naar de eindbestemming.

Echt uitleg vroeg hij niet dacht ik. Tis gewoon even een klappeke doen.
Er is in deze nieuwsgroup maanden geleden een posting van mezelf geweest
waarin ik onze antispammaatregel uitgeleg.
U kan hem zelf terugvinden als u even zoekt.

Glenn


> (Ik denk...) Andy post zijn vraag hier omdat hij ziet dat Tiscali een
> 4xx error afgeeft mocht de SMTP connectie naar het MX record van de
> verzender niet tot stand komen. Een 4xx error betekend dat de MTA na
> $interval weer probeert de email te versturen, de email blijft zolang in
> de queue staan.
>
> Door het in de nieuwsgroep te posten vraagt Andy eigenlijk of anderen
> dit ook hebben gemerkt, en vraagt (publiekelijk) om uitleg van Tiscali.
> Omdat het een vrij grote impact kan hebben op de performance van
> mailservers (grote queue, langzame(re) aflevering) is het IMO juist goed
> dat het hier gepost / besproken wordt [1]. Beter dan 99% van de "$HOST
> ligt weer plat" postings :)

[Wannes]

op/on 16-10-2003 15:48 schreef/wrote Glenn Plas :

> heb ondertussen te weten gekomen dat de mensen die de reclame doorzenden
> een firma is die ingehuurd werd door mr Frank Verstraeten.

Meester Verstraeten ??? :o)

>'die hadden een lijst vaan 40 000 klanten' <endquote> .... Zucht ....

Tsja, naïviteit kan vergaande gevolgen hebben.

[Jan Reilink]

[Zou je aub niet willen topposten? Thanks :)]

Glenn Plas wrote:

> bingo. Niet slecht gedacht.... maar vergeet niet dat al die mails 'die
> problemen kunnen veroorzaken' in het omgekeerde situatie geval in ONZE queues zullen
> staan (+de bounces die niet kunnen worden afgeleverd). Dan zou de impact
> enkel voor ons zijn ... nu is het iedereen die een beetje impacted is.
>

Het ligt natuurlijk een beetje aan de verzendende host, maar 550 dan :)
Uit Andy's voorbeeld:
Trying 62.235.13.209...
Connected to mailer.tiscali.be.
Escape character is '^]'.
220 ESMTP Tiscali.be. NO UBE/UCE tolerated.
ehlo blah
250-mailer.tiscali.be Hello blah [195.238.24.200]

Volgens de RFC's zou de EHLO gevolgt moeten worden door een valide FQDN,
geen FQDN als EHLO statement -> 550 Of je zou zelfs op message-id kunnen
filteren (ik weet dat wij, bijvoorbeeld, dit ook niet doen...), geen FQDN
achter de '@' -> droppen.
Het ligt er een beetje aan hoe ver je wilt gaan.

> Dus zo erg kan het niet zijn. Ook meteen een duw in de rug naar anderen
> toe om spam/bulk mail niet zomaar door te sturen naar de eindbestemming.
>

Het princiepe van een nieuwe connectie (terug-)opzetten naar het MX record
van de verzender ken ik alleen van ETRN, wat wordt er aan data verstuurd? of
wordt er alleen gekeken of de MX reageert?
Als er data wordt verstuurd, dan kan ik me voorstellen dat sommige ISP's
niet blij zullen zijn met de toename in bandbreedte verbruik.

> Echt uitleg vroeg hij niet dacht ik. Tis gewoon even een klappeke doen.
> Er is in deze nieuwsgroup maanden geleden een posting van mezelf geweest
> waarin ik onze antispammaatregel uitgeleg.
> U kan hem zelf terugvinden als u even zoekt.
>

<http://groups.google.com/groups?selm=3F03FA7D.6090408%40be.tiscali.com>

--
Met vriendelijke groet / Best regards,
Jan Reilink

VEVIDA Nederland BV

[Glenn Plas]

> Het ligt natuurlijk een beetje aan de verzendende host, maar 550 dan :)
> Uit Andy's voorbeeld:
> Trying 62.235.13.209...
> Connected to mailer.tiscali.be.
> Escape character is '^]'.
> 220 ESMTP Tiscali.be. NO UBE/UCE tolerated. ehlo blah
> 250-mailer.tiscali.be Hello blah [195.238.24.200]
>
> Volgens de RFC's zou de EHLO gevolgt moeten worden door een valide FQDN,
> geen FQDN als EHLO statement -> 550 Of je zou zelfs op message-id kunnen
> filteren (ik weet dat wij, bijvoorbeeld, dit ook niet doen...), geen
> FQDN achter de '@' -> droppen.
> Het ligt er een beetje aan hoe ver je wilt gaan.

Wij aanvaarden bogus HELO's want moesten wij dat weigeren kwam er geen mail meer binnen, dat is een van de weinige die we door de vingers zien. Maar we eisen wel dat de envelop RFC compliant is en de server ook. Mensen die mail from:<> weigeren op hun m
achines kunnen ons niet mailen ... punt. Staat ook in de RFC's dat dat moet werken...

Die callback moet wel antwoorden met een 4xx error ... wat als de remote MX even down is ? we kunnen de mail toch niet weggooien omdat er even geen connectie was ? Dus moesten wij een 550 ging er heel wat mail verloren

>> Dus zo erg kan het niet zijn. Ook meteen een duw in de rug naar
>> anderen toe om spam/bulk mail niet zomaar door te sturen naar de
>> eindbestemming.
>>
> Het princiepe van een nieuwe connectie (terug-)opzetten naar het MX
> record van de verzender ken ik alleen van ETRN, wat wordt er aan data
> verstuurd? of wordt er alleen gekeken of de MX reageert? Als er data
> wordt verstuurd, dan kan ik me voorstellen dat sommige ISP's niet blij
> zullen zijn met de toename in bandbreedte verbruik.

erm, er is wel een connectie cache aanwezig, een mailserver die in staat is 200 mails door te sturen van emailadress xyz@mijnserver.be moet in staat zijn 1 NULL connectie van ons te ontvangen. In essentie starten we een SMTP chat en wanneer de remote MTA
zegt: 250 OK dan breken we af zonder mail te sturen. (RSET/QUIT)

Is toch eerlijk, die dat ons veel mailt krijgt veel reverse checks, die ons weinig mailt minder ... Het enige wat je als admin jezelf kan afvragen (remote) is wat zijn al die correct afgebroken SMTP sessies eigenlijk.

Ons standpunt is: Als je resources hebt om ons te kunnen mailen moet je maar in staat zijn minder dan 1 mailtje terug te ontvangen... Moesten wij dit niet doen ging er toch een bounce message in hun richting terug voor ELKE slechte mail dat naar ons komt
... het is het 1 of het ander ...

>> Echt uitleg vroeg hij niet dacht ik. Tis gewoon even een klappeke
>> doen. Er is in deze nieuwsgroup maanden geleden een posting van mezelf
>> geweest waarin ik onze antispammaatregel uitgeleg. U kan hem zelf
>> terugvinden als u even zoekt.
>>
> <http://groups.google.com/groups?selm=3F03FA7D.6090408%40be.tiscali.com>

Glenn
>

[Stefaan]

"Glenn Plas" <gplas@be.tiscali.com> schreef in bericht
news:pan.2003.10.16.15.48.17.687478.951@be.tiscali .com...
> On Thu, 16 Oct 2003 15:37:19 +0200, Stefaan wrote:
>
> > Ze hebben de grootste.
> > Op alle gebieden.
>
> op ALLE gebieden ? Zonder natural exercises ?


Mogelijk met behulp vd "natural enlargers" unsolicited mailings
die ze met "alle macht" pogen te stoppen ;-)


> Ik heb Belgacom niet nodig om een user te
> blocken, om een telefoonnr te blacklisten enzv. En BCM heeft ons ook
> niet nodig om hun eigen netwerk te cleanen.

Begrijpelijk.

Alhoewel sommige users de AUP van hun ISP wel heel ver uitrekken.
En sommige ISPs de balans tussen het verlies v een grote klant
versus relatief 'eenmalig' ongemak
blijkbaar soms niet echt kunnen vinden.


>
> heb ondertussen te weten gekomen dat de mensen die de reclame doorzenden
> een firma is die ingehuurd werd door mr Frank Verstraeten. 'die hadden
> een lijst vaan 40 000 klanten' <endquote> .... Zucht ....

Die "onaantastbare" uit A?
Klanten? (kuch)
Ik zou toch uw juridische dienst contacteren....


> > Ehem.
> >
> > Hey, Andy, Glenn, my best friends,
> > hebben jullie geen mail of telefoons om ons deze overlast *vooraf te
> > besparen?
>
> Wat zou ik beter met een telefoon in mijn hand kunnen doen dan zonder ?
> Suggesties welkom.


U doet uw best :)

Wat ik niet helemaal begrijp is de techniek waarmee die firma
mailservers misbruikt - er is verder sinds enige tijd relevante wetgeving.

Als die info publiek is en uw netwerk niet in gevaar brengt:
ik lees ze graag.


> over welke overlast heb je het eigenlijk ? De spam

Inderdaad.

[Jan Reilink]

[nu nog linewrapping op 73-78 tekens en het is perfect :-)]

Glenn Plas wrote:

[HELO]
> Wij aanvaarden bogus HELO's want moesten wij dat weigeren kwam er geen
> mail meer binnen, dat is een van de weinige die we door de vingers zien.
> Maar we eisen wel dat de envelop RFC compliant is en de server ook.
> Mensen die mail from:<> weigeren op hun machines kunnen ons niet mailen ...
> punt. Staat ook in de RFC's dat dat moet werken...
>

Klopt, from:<> is o.a. voor bounces.

Naar mijn mening is een bogus HELO/EHLO ernstiger dan een bogus message-id,
het is niet voor niets dat die betreffende RFC is aangepast (van "verplicht
@fqdn" naar "het liefst @fqdn", als ik het me goed herinner). Maar ja,
helemaal geen mail meer ontvangen is natuurlijk geen optie, soms moet je
keuzes maken ;-)

> Die callback moet wel antwoorden met een 4xx error ... wat als de
> remote MX even down is ? we kunnen de mail toch niet weggooien
> omdat er even geen connectie was ? Dus moesten wij een 550 ging er
> heel wat mail verloren
>

Klopt, nu is er wel een groot verschil in corperate mailservers en private
mailservers, maar ik ken ze die het (zouden?) doen.

[...]
>>Het princiepe van een nieuwe connectie (terug-)opzetten naar het MX
>>record van de verzender ken ik alleen van ETRN, wat wordt er aan data
>>verstuurd? of wordt er alleen gekeken of de MX reageert? Als er data
>>wordt verstuurd, dan kan ik me voorstellen dat sommige ISP's niet blij
>>zullen zijn met de toename in bandbreedte verbruik.
>
> erm, er is wel een connectie cache aanwezig, een mailserver die in
> staat is 200 mails door te sturen van emailadress xyz@mijnserver.be
> moet in staat zijn 1 NULL connectie van ons te ontvangen. In
> essentie starten we een SMTP chat en wanneer de remote MTA zegt:
> 250 OK dan breken we af zonder mail te sturen. (RSET/QUIT)
>

Is inderdaad een nette manier, dank voor de uitleg.

--
Met vriendelijke groet / Best regards,
Jan Reilink

VEVIDA Nederland BV

[frank@openminds.be]

Glenn Plas <gplas@be.tiscali.com> wrote:
> Die banner hebben we daar al ongeveer een maand of 6 staan trouwens even
> lang als onze anti-spam maatregelen. Nog nooit eerder gezien ?

> Nog vragen verder over hoe het werkt ? Altijd welkom.

Glenn,

kan je even kort technisch uitleggen hoe de controle gebeurt? Een RCPT
TO poging op de remote server?

Welke voorzieningnen heb je getroffen om te verhinderen dat 2
mailservers die hetzelfde principe volgen, in een loop terechtkomen?
Wat doe je met MX hosts? controleer je ze allemaal? Enkel de eerste?

Vriendelijke groeten,
Frank Louwers

--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

[frank@openminds.be]

Stefaan <nomail@email.invalid> wrote:

> Die "onaantastbare" uit A?

ah, komt het van hen?

Vriendelijke groeten,
Frank Louwers

--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

[Andy De Petter]

xeno <xenoREMOVE@pandora.be> wrote:
> On Thu, 16 Oct 2003 13:37:19 GMT, "Stefaan" <nomail@email.invalid>
> wrote:
>
>>Hey, Andy, Glenn, my best friends,
>>hebben jullie geen mail of telefoons om ons deze overlast *vooraf te
>>besparen?
>
> BC hecht meer belang aan het feit dat ze concurrenten publiekelijk
> kunnen proberen belachelijk maken door te wijzen op (mogelijke)
> fouten. Dat BC op zijn beurt zelf blind en doofstom is als er
> problemen gemeld worden, dat is dan weer normaal.

Dit gaat niet over het publiekelijk belachelijk maken van concurrenten. Dit gaat over een technische opmerking en vraag, die ondertussen reeds verduidelijkt is.

>
> De grootste ISP van Belgie maakt immers geen fouten, het zijn enkel de
> kleine overblijvende concurrentjes die maar wat zitten 'prutsen'...

Ik heb nooit gezegd, dat wij geen fouten maken.

-Andy

--
Andy De Petter - http://www.techos.be/andy - naql@gunvobk.or (ROT13)
Expert IT Analyst - Belgacom ANS/NTA/NST - http://www.belgacom.be
"Cogito Ergo Sum - I think, therefore I am."
-- R. Descartes

[Andy De Petter]

Jan Reilink <janreilink@vevida.nl> wrote:
> Stefaan wrote:
>>
>
> In Nederand hebben we daar IRC voor ;-))
> Spreken we overigens niet liever over "conculega's / collega's" i.p.v.
> "concurrenten"? Klinkt wat vriendelijker :P
>

Hier hebben we daar ook IRC voor, maar 'k ken toevallig geen irc'ende Tiscali engineers. ;)

-Andy

--
Andy De Petter - http://www.techos.be/andy - naql@gunvobk.or (ROT13)
Expert IT Analyst - Belgacom ANS/NTA/NST - http://www.belgacom.be
"Cogito Ergo Sum - I think, therefore I am."
-- R. Descartes

[Andy De Petter]

Glenn Plas <gplas@be.tiscali.com> wrote:
>
> Echt uitleg vroeg hij niet dacht ik. Tis gewoon even een klappeke doen.
> Er is in deze nieuwsgroup maanden geleden een posting van mezelf geweest
> waarin ik onze antispammaatregel uitgeleg.
> U kan hem zelf terugvinden als u even zoekt.
>

Glenn,

Welk nog een kleine bedenking: wat gebeurt er wanneer een andere provider hetzelfde systeem als jullie implementeert? Loop van reversed connections, tot de file descriptors opgebruikt zijn? Of staat er een limiet op het aantal reversed connections naar
eenzelfde host?

-Andy

--
Andy De Petter - http://www.techos.be/andy - naql@gunvobk.or (ROT13)
Expert IT Analyst - Belgacom ANS/NTA/NST - http://www.belgacom.be
"Cogito Ergo Sum - I think, therefore I am."
-- R. Descartes

[Andy De Petter]

Glenn Plas <gplas@be.tiscali.com> wrote:
>
> Ons standpunt is: Als je resources hebt om ons te kunnen mailen moet je maar in staat zijn minder dan 1 mailtje terug te ontvangen... Moesten wij dit niet doen ging er toch een bounce message in hun richting terug voor ELKE slechte mail dat naar ons ko
mt ... het is het 1 of het ander ...
>

Persoonlijk vind ik het een heel goed systeem, maar 'k denk dan wel ook aan al de manieren die kunnen worden gebruikt, om het systeem te misbruiken, door (D)DoS :(

-a

--
Andy De Petter - http://www.techos.be/andy - naql@gunvobk.or (ROT13)
Expert IT Analyst - Belgacom ANS/NTA/NST - http://www.belgacom.be
"Cogito Ergo Sum - I think, therefore I am."
-- R. Descartes

[Stefaan]

<frank@openminds.be> schreef in bericht
news:bmmjtv$nuade$2@ID-103399.news.uni-berlin.de...
> Stefaan <nomail@email.invalid> wrote:
>
> > Die "onaantastbare" uit A?
>
> ah, komt het van hen?

Volgens de Senior System Administrator van Tiscali,
en die kan het weten (zie ook de 3rd line support post van een Tiscali
medewerker)

Tiscali heeft blijkbaar al juridische stappen ondernomen tegen
het ingehuurde bedrijf - maar of dat F uit A zal stoppen
is zeer twijfelachtig.

Er zijn blijkbaar genoeg mensen-met-invloed in dit land die
nog steeds gewoon 100% ongestoord doen waar ze zin in hebben.
Strafbaar of niet.
Ik geraak een beetje off-topic, soit..

gr,

[Andy De Petter]

frank@openminds.be wrote:
> Glenn Plas <gplas@be.tiscali.com> wrote:
>> Die banner hebben we daar al ongeveer een maand of 6 staan trouwens even
>> lang als onze anti-spam maatregelen. Nog nooit eerder gezien ?
>
>> Nog vragen verder over hoe het werkt ? Altijd welkom.
>
> Glenn,
>
> kan je even kort technisch uitleggen hoe de controle gebeurt? Een RCPT
> TO poging op de remote server?

Yup, denk het wel, want ik heb gisteren geprobeerd om een MX voor een van onze servers te laten pointen naar localhost, en dan kreeg ik een andere foutmelding (Bad Recipient). Dus server maakt een reversed connection, en checkt de RCPT TO.

>
> Welke voorzieningnen heb je getroffen om te verhinderen dat 2
> mailservers die hetzelfde principe volgen, in een loop terechtkomen?
> Wat doe je met MX hosts? controleer je ze allemaal? Enkel de eerste?
>
> Vriendelijke groeten,
> Frank Louwers
>

-a

--
Andy De Petter - http://www.techos.be/andy - naql@gunvobk.or (ROT13)
Expert IT Analyst - Belgacom ANS/NTA/NST - http://www.belgacom.be
"Cogito Ergo Sum - I think, therefore I am."
-- R. Descartes

[Esther]

Op Thu, 16 Oct 2003 20:48:15 +0000, schreef Andy De Petter:

> Dit gaat niet over het publiekelijk belachelijk maken van concurrenten.
> Dit gaat over een technische opmerking en vraag, die ondertussen reeds
> verduidelijkt is.
>
>
Je naam om je hier hopeloos belachelijk te maken heb je al lang dus er zal
niemand meer opkijken dat je dit terug doet voor de zoveelste keer hoor
:-)

>
> Ik heb nooit gezegd, dat wij geen fouten maken.

Inderdaad kan je nog moeilijk ontkennen gezien de wereldbekendheid die de
knoeiboel van Skynet intussen geniet, je zou voor minder somber lopen :-(

[Glenn Plas]

kleine correctie, vergeet niet dat rcpt to: ALTIJD word gechecked om
uiteindelijk afgeleverd te worden, wat wij checken is de mail from:

er zijn geen loop problemen. Deze feature in exim is redelijk foolproof.
Ik begrijp niet goed waar je die loop zou zien ...

Glenn


> Yup, denk het wel, want ik heb gisteren geprobeerd om een MX voor een
> van onze servers te laten pointen naar localhost, en dan kreeg ik een
> andere foutmelding (Bad Recipient). Dus server maakt een reversed
> connection, en checkt de RCPT TO.
>
>
>> Welke voorzieningnen heb je getroffen om te verhinderen dat 2
>> mailservers die hetzelfde principe volgen, in een loop terechtkomen?
>> Wat doe je met MX hosts? controleer je ze allemaal? Enkel de eerste?
>>
>> Vriendelijke groeten,
>> Frank Louwers
>>
>>
> -a
>

[Physicman]

Hello Glenn, Andy and everyone else ;)

On Fri, 17 Oct 2003 10:32:25 +0200
Glenn Plas <gplas@be.tiscali.com> wrote:
> kleine correctie, vergeet niet dat rcpt to: ALTIJD word gechecked om
> uiteindelijk afgeleverd te worden, wat wij checken is de mail from:
>
> er zijn geen loop problemen. Deze feature in exim is redelijk
> foolproof.
> Ik begrijp niet goed waar je die loop zou zien ...
>
A small link is better than a long explanation. This is called the
'callout verification' in exim and you can see it's description there:
http://www.exim.org/exim-html-4.20/doc/html/spec_37.html#IX2231

> Glenn
>

Regards,

--
,''`. Christopher `Physicman' Bodenstein <cb@physicman.net>
: :' : Physicman.Net : http://www.physicman.net/
`. `' Debian GNU/Linux : http://www.debian.org/
`- Debian IPv6 : http://people.debian.org/~csmall/ipv6/

[Glenn Plas]

Indeed ... bjr Christophe btw.... comment ca va la ? Laurent dit
bonjour ;-)

nog een mooie link hier:.
http://sourceforge.net/docman/display_doc.php?docid=6747&group_id=1

Glenn

On Fri, 17 Oct 2003 10:56:09 +0200, Physicman wrote:

> Hello Glenn, Andy and everyone else ;)
>
> On Fri, 17 Oct 2003 10:32:25 +0200
> Glenn Plas <gplas@be.tiscali.com> wrote:
>> kleine correctie, vergeet niet dat rcpt to: ALTIJD word gechecked om
>> uiteindelijk afgeleverd te worden, wat wij checken is de mail from:
>>
>> er zijn geen loop problemen. Deze feature in exim is redelijk
>> foolproof.
>> Ik begrijp niet goed waar je die loop zou zien ...
>>
> A small link is better than a long explanation. This is called the
> 'callout verification' in exim and you can see it's description there:
> http://www.exim.org/exim-html-4.20/doc/html/spec_37.html#IX2231
>
>> Glenn
>>
>>
> Regards,
>

[xeno]

On 16 Oct 2003 20:48:15 GMT, Andy De Petter <andy@brol.be> wrote:

>> BC hecht meer belang aan het feit dat ze concurrenten publiekelijk
>> kunnen proberen belachelijk maken door te wijzen op (mogelijke)
>> fouten. Dat BC op zijn beurt zelf blind en doofstom is als er
>> problemen gemeld worden, dat is dan weer normaal.
>
>Dit gaat niet over het publiekelijk belachelijk maken van concurrenten. Dit gaat over een technische opmerking en vraag, die ondertussen reeds verduidelijkt is.

Niet ? Wat was er zo moeilijk om dit probleem eerst onderling via een
telefoontje aan te kaarten ? Waarom moest dit hier perse direct via
publieke weg gaan ?

Uiteraard kan u nu het argument aanhalen dat "de mensen dan ook op de
hoogte waren"... Ik vind het gewoon laag.

Als andere mensen hier terecht over een Skynet/BC probleem klagen, dan
is Stefan er vaak als de kippen bij om het via mail verder af te
handelen, kwestie van de vuile was zo veel mogelijk binnen te houden.
En dan komt u als techo hier ff een andere ISP een veeg uit de pan
geven zonder eerst onderling het probleem te melden.

Dit lijkt mij meer een verborgen lastercampagne dan het 'melden van
een probleem'.

>> De grootste ISP van Belgie maakt immers geen fouten, het zijn enkel de
>> kleine overblijvende concurrentjes die maar wat zitten 'prutsen'...
>
>Ik heb nooit gezegd, dat wij geen fouten maken.

Waarom blijft die Skynet spam-soap dan duren ? Waarom blijven jullie
mailservers met momenten 10 uur of langer nodig hebben om mails bij
klanten te krijgen ? Waarom blijft jullie newsserver pokketraag na
kantooruren ?

Zaken die hier al 101 keer aangehaald zijn, en waar jullie gewoon
weinig of niets aan doen. Ja... beweren dat er niets aan de hand is
terwijl het probleem gewoon blijft bestaan...

En kom weer niet af met het verhaaltje dat jullie nu en dan problemen
hebben wegens het massaal aantal klanten dat jullie hebben doordat
jullie de grootste ISP in Belgie zouden zijn...

Als je dan toch de pretentie hebt de grootste te zijn of willen zijn,
zie dan ook dat je het aankan...

[frank@openminds.be]

Glenn Plas <gplas@be.tiscali.com> wrote:
> kleine correctie, vergeet niet dat rcpt to: ALTIJD word gechecked om
> uiteindelijk afgeleverd te worden, wat wij checken is de mail from:

> er zijn geen loop problemen. Deze feature in exim is redelijk foolproof.
> Ik begrijp niet goed waar je die loop zou zien ...

Glenn,

Een van jullie mailservers (bv mail-in.tiscali.be) gebruikt dit systeem,
wij momenteel niet. Ik stuur je een mail. Onze MTA connecteert met
jullie server, doet een MAIL FROM: frank @ openminds.be, RCPT TO:
glennsomething @ tiscali.be. Op dat moment doet jullie server een poging
om frank @ openminds.be te controleren. Jullie MTA zal dus een connectie
maken met mail.openminds.be, en een MAIL FROM: something @ tiscali.be
RCPT TO: frank @ openminds.be proberen. Dit lukt, geen probleem, adres
ok, mail mail mag door.

Stel nu dat wij hetzelfde implementeren op mail.openminds.be als jullie
op mail-in.tiscali.be. Ik stuur je opnieuw mail. Alles is t zelfde, tot
op het moment dat jullie mailserver die callback doet, jullie MTA doet
opnieuw MAIL FROM: something @ tiscali.be RCPT TO: frank @ openminds.be.
Onze MTA ziet dan "ah, iemand die mail probeert te sturen, ik doe een
callback". Onze MTA gaat met jullie MTA connecteren, ... zie je de loop?

Welke voorzieningen hebben jullie hiertegen genomen?


Vriendelijke groeten,
Frank Louwers

--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

[stef-spam@iguana.be]

frank@openminds.be wrote:
> Glenn Plas <gplas@be.tiscali.com> wrote:
> Stel nu dat wij hetzelfde implementeren op mail.openminds.be als jullie
> op mail-in.tiscali.be. Ik stuur je opnieuw mail. Alles is t zelfde, tot
> op het moment dat jullie mailserver die callback doet, jullie MTA doet
> opnieuw MAIL FROM: something @ tiscali.be RCPT TO: frank @ openminds.be.
> Onze MTA ziet dan "ah, iemand die mail probeert te sturen, ik doe een
> callback". Onze MTA gaat met jullie MTA connecteren, ... zie je de loop?

De callback gebruikt <> als envelope sender. Hierdoor is het niet
mogelijk in loops te raken.

> Welke voorzieningen hebben jullie hiertegen genomen?

Je hoeft er geen tegen te nemen.

stef

[frank@openminds.be]

stef-spam@iguana.be wrote:
> frank@openminds.be wrote:
>> Glenn Plas <gplas@be.tiscali.com> wrote:
>> Stel nu dat wij hetzelfde implementeren op mail.openminds.be als jullie
>> op mail-in.tiscali.be. Ik stuur je opnieuw mail. Alles is t zelfde, tot
>> op het moment dat jullie mailserver die callback doet, jullie MTA doet
>> opnieuw MAIL FROM: something @ tiscali.be RCPT TO: frank @ openminds.be.
>> Onze MTA ziet dan "ah, iemand die mail probeert te sturen, ik doe een
>> callback". Onze MTA gaat met jullie MTA connecteren, ... zie je de loop?

> De callback gebruikt <> als envelope sender. Hierdoor is het niet
> mogelijk in loops te raken.

ah, ok. thnx voor de info...



Vriendelijke groeten,
Frank Louwers

--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium