Onderwerp: Tiscali SMTP?

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

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

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

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
>

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

"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?

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'...

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

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

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

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 ??? )

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

Tsja, naïviteit kan vergaande gevolgen hebben.

[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...be.tiscali.com>

--
Met vriendelijke groet / Best regards,
Jan Reilink

VEVIDA Nederland BV

> 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...be.tiscali.com>

Glenn
>

"Glenn Plas" <gplas@be.tiscali.com> schreef in bericht
newsan.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.

[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