Blok van e-mail

[snarf]

We hebben hier een erg vervelend probleem.

We kunnen geen mail versturen naar een aantal providers (oa Zonnet). Het lijkt erop dat we op een blacklist voorkomen die ons ip heeft opgenomen.

Door UU-net en andere bedrijven is inmiddels getest en onze mailserver heeft idd geen open relay. Er kan dus niet door externen via onze server hebben gemaild. De pogingen zijn er wel, maar worden allemaal afgevangen.

Dit wordt op openrbl.org weergegeven:

DNSBL Lookup 194.229.255.194 http://openrbl.org/ip/194/229/255/194.htm
Lookup 194.229.255.194 (fmh.nl) in 11+21 Zones
AS: 194.229.0.0/16 AS702 UUNET Technologies, Inc. Ashburn/Virginia
Net 194.229.255.192-199 FMH @mega.com.ru
Results: Positive=1, Negative=31 (2003-07-15 13:13:46 UTC)
XBL/uu-net: global2000hosting.net; [e-mail]: webform;
for NETBLK-UU-208-243-248-D1; for NETBLK-WHIT2UU1; for NETBLK-UU-206-65-169-128-D3;
for UU-63-89-113-D1 / Asch Web Hosting; for evidence-eliminator on 81.86.64.234;
uu.net is full of spammers; bulletproofwebhosting.net; NS for bzah.com (Empire Towers);
scelson; exactis/247media
Negative 31: @COUNTRY @DYNAMIC @ISP @SPAM ASS BLARS BONDED BOPM DRBL DSBL EASYNET FIVETEN INTERSIL JIPPGMA LNSG NJABL NOMORE ORDB OSIRU PSBL REYNOLDS RFC_IPWH SBL SORBS SPAMBAG SPAMCOP SPAMRBL SPAMSITE SPEWS UPL WYTNIJTO

--------------------------------------------------------------------------------
Hints for 194.229.255.194: (external, use BACK or ALT-LEFT when done)
Track "fmh.nl" at [Whois & Abuse|SpamCop*]
Search "194.229.255.194" at [Google|SpamCop*|SenderBase] [MAPS|Schlund]
CHECK: Nominate Relay-Test at: [OSIRU|DEVNULL|ORDB] [Add Comment]


Nou lijkt het wel alsof er in Rusland een server staat met dezelde ip-range als ons!!! Dat lijkt me sterk want onze mailserver staat dag en nacht aan. Alleen tijdens een reboot zouden ze ons ip hebben kunnen gebruiken?! Als je verder gaat kijken bij de positive result komen we terecht bij dit:


DNSBL Zones WHERE name=\'XBL\'
Name XBL - eXtreme Block List
Zone dns://xbl.selwerd.cx (Sample: 194.229.255.194)
Homepage http://selwerd.cx/xbl/
Short
Description private list, implemented as negative whitelist.
lists most of the internet, high risk, dont use for blocking.
Additions,
Nomination manual after receiving spam, usually in big chunks
Removal
or Retest nope, dont bother unless you have a good reason to send mail to one of their local users

Het lijkt er dus op dat zij ons op hun list hebben staan en dat bijvoorbeeld een Zonnet gebruik maakt van deze list. Ondanks dat onze server volledig dichtstaat weigeren ze ons van de list te halen. Ongeveer 3-4 weken geleden zijn de problemen begonnen. Het is erg vervelend want we kunnen nu niet mailen naar diverse bedrijven/personen.

UU-net en diverse andere bedrijven weten allemaal niet hoe dit moet worden opgelost.

Wat is hier aan te doen en HOE kunnen we er wat aan doen???

[Zwelgje]

als je je mailserver nu eens zo configged dat hij eerst even de mail naar de server van uunet stuurt (smtp.provider.nl)

dan handelt hun server de versturing van de mail wel af, je kan er vanuit gaan dat de mailserver van uunet niet op die blacklist staat.

dit is ook vaak het probleem bij bedrijven die via een adsl lijntje hun mailservertje (pop3 middels exchange 2000 sbs) hebben draaien, zij sturen rechtstreeks via dns de mail, en de ontvangende server ziet dit vaak als een 'relay' (omdat ze geen eigen mx record hebben in dns)

[Bjornski]

Ik heb hetzelfde probleem gehad met ORDB en MERAK Mail server. Zet SMTP Authenticatie aan en sta alleen mail delivery toe naar lokale domeinen. Met andere woorden, zorg dat je mailserver echt geen open relay is en potdicht zit.
Biedt je server vervolgens aan voor retesting.
(CHECK: Nominate Relay-Test at: [OSIRU|DEVNULL|ORDB] [Add Comment])

In de tussentijd (je wilt toch mailen waarschijnlijk) zou ik gewoon al mijn mail naar een SMTP relay binnen je netwerk sturen. Zet even een kale mailserver op in je netwerk of (als UUNET dat heeft / leuk vindt) stuur alles door de SMTP van UUNET heen, zoals zwelgje hierboven uitlegt.

[MikeN]

Je kan doen wat je wil, je zal niet van die lijst afkomen. Je bent geblacklist omdat, quote:

uu.net is full of spammers;

Heel uu.net is dus gewoon geblacklist.

In de verdere beschrijving wordt ook afgeraden deze lijst voor block-doeleinden te gebruiken. Dat Zonnet verkeerde blacklists gebruikt is al langer bekend (even searchen zal je dat wel laten zien) en is ronduit belachelijk imho. Probeer Zonnet hierover te emailen, alhoewel het volgens mij weinig zin zal hebben. Ook k un je aan je provider een andere IP in een andere range vragen.

[igmar]

snarf schreef op 15 juli 2003 @ 15:37:
Door UU-net en andere bedrijven is inmiddels getest en onze mailserver heeft idd geen open relay. Er kan dus niet door externen via onze server hebben gemaild. De pogingen zijn er wel, maar worden allemaal afgevangen.

Wen d'r maar vast aan, UUNet gaat voor de status van intranet.

DNSBL Zones WHERE name=\'XBL\'
Name XBL - eXtreme Block List
Zone dns://xbl.selwerd.cx (Sample: 194.229.255.194)
Homepage http://selwerd.cx/xbl/

Sja.. als je met die lijst gaat blocken krijg je zeker geen mail meer binnen.

Wat is hier aan te doen en HOE kunnen we er wat aan doen???

Niks. Een andere ISP nemen die wel een fatsoenlijke abuse afdeling heeft.

[mvdejong]

snarf schreef op 15 July 2003 @ 15:37:
Nou lijkt het wel alsof er in Rusland een server staat met dezelde ip-range als ons!!! Dat lijkt me sterk want onze mailserver staat dag en nacht aan. Alleen tijdens een reboot zouden ze ons ip hebben kunnen gebruiken?!

Niemand kan verhinderen dat een server aan de andere kant van de wereld hetzelfde IP-adres gebruikt. Alleen op een lokaal net met DHCP-servers kan dat worden voorkomen, en dan alleen als de DHCP-server eerst pingt of een IP-adres vrij is voordat het (opnieuw) wordt uitgegeven. Afhankelijk van de specifieke DHCP-server kun je dat soms aan- of uitzetten.

Maar ook dan gebeurt het dat gebruikers van hun ISP een dynamisch IP-adres krijgen, maar een web-server willen runnen zonder van DynDNS gebruik te maken. Ze zetten dan hard het van DHCP verkregen IP-adres op hun interface, en dan hangt het helemaal van de ISP af of en hoelang dat goed gaat.

Het heeft weinig zin om over het Internet heen dit soort IP-hijacking te plegen, aangezien de routering wel degelijk zal zorgen dat al dat soort pakketjes naar (de ISP van) de officiele gebruiker van dat IP-adres gaat.

Wat natuurlijk wel kan gebeuren is dat iemand voor een intern netwerk toch een niet-private IP-range gebruikt. Dat kan tot heerlijk verwarrende effecten zorgen als de NAT dan niet goed is ingericht.

[ Voor 8% gewijzigd door mvdejong op 17-07-2003 11:42 ]

[Harrie666]

mvdejong schreef op 17 July 2003 @ 11:40:
[...]

Niemand kan verhinderen dat een server aan de andere kant van de wereld hetzelfde IP-adres gebruikt. Alleen op een lokaal net met DHCP-servers kan dat worden voorkomen, .

mag jij me uitleggen hoe die pakketten dan ooit naar de andere kant van de wereld gerouteerd worden. Lijkt mij namelijk niet echt mogelijk om maar even je gejatte ip-reeks gerouteerd te krijgen.

[Flyduck]

mvdejong schreef op 17 July 2003 @ 11:40:
[...]

Niemand kan verhinderen dat een server aan de andere kant van de wereld hetzelfde IP-adres gebruikt. Alleen op een lokaal net met DHCP-servers kan dat worden voorkomen, en dan alleen als de DHCP-server eerst pingt of een IP-adres vrij is voordat het (opnieuw) wordt uitgegeven. Afhankelijk van de specifieke DHCP-server kun je dat soms aan- of uitzetten.

Maar ook dan gebeurt het dat gebruikers van hun ISP een dynamisch IP-adres krijgen, maar een web-server willen runnen zonder van DynDNS gebruik te maken. Ze zetten dan hard het van DHCP verkregen IP-adres op hun interface, en dan hangt het helemaal van de ISP af of en hoelang dat goed gaat.

Het heeft weinig zin om over het Internet heen dit soort IP-hijacking te plegen, aangezien de routering wel degelijk zal zorgen dat al dat soort pakketjes naar (de ISP van) de officiele gebruiker van dat IP-adres gaat.

Wat natuurlijk wel kan gebeuren is dat iemand voor een intern netwerk toch een niet-private IP-range gebruikt. Dat kan tot heerlijk verwarrende effecten zorgen als de NAT dan niet goed is ingericht.

Uiteraard kan iemand anders hetzelfde IP adres instellen aan de andere kant van de wereld,.. maar ze komen er never nooit niet mee het internet op.

Als je je interne range niet goed insteld (bv op 194.100.200.0 oid), kan dat idd verwarrende effecten geven, echter alleen voor de gebruikers achter het NAT.

[mvdejong]

Harrie666 schreef op 17 juli 2003 @ 11:57:
[...]


mag jij me uitleggen hoe die pakketten dan ooit naar de andere kant van de wereld gerouteerd worden. Lijkt mij namelijk niet echt mogelijk om maar even je gejatte ip-reeks gerouteerd te krijgen.

Heb je mijn hele reply gelezen :

Het heeft weinig zin om over het Internet heen dit soort IP-hijacking te plegen, aangezien de routering wel degelijk zal zorgen dat al dat soort pakketjes naar (de ISP van) de officiele gebruiker van dat IP-adres gaat.

[Coen Rosdorff]

Makkelijkste oplossing: Gewoon weggaan bij een clue-less provider die wel de klok heeft horen luiden maar niet waar de klepelhangt.

Zomaar ongevraagd mail voor klanten gaan blokkeren adhv lijsten die niet voor dat doel bestaan is echt niet acceptabel.

[MikeN]

little_soundman schreef op 17 July 2003 @ 15:51:
Makkelijkste oplossing: Gewoon weggaan bij een clue-less provider die wel de klok heeft horen luiden maar niet waar de klepelhangt.

Zomaar ongevraagd mail voor klanten gaan blokkeren adhv lijsten die niet voor dat doel bestaan is echt niet acceptabel.

Dat moet je niet tegen de TS zeggen maar tegen iedereen die Zonnet gebruikt. Veel succes, maar ik denk echt niet dat je al die mensen daar weg krijgt.

[raymonvdm]

Ze blokken geen mail voor klanten maar spammers.

Ik heb zelf bij ordb.org op de lijst gestaan die ook door onder andere kennisnet en zonnet wordt gebruikt en dat kwam door een configuratie fout van m`n mailserver.

Was voor veel testen geen relay maar wel voor 2 of 3 van 64. Bleek dat bij m`n domainscreen stond *.domein.nl terwijl dit moest zijn *domein.nl.

Nadeel is inderdaad dat je niet meer kan mailen naar veel providers oplossing is echter simpel gebruik smtp forwarding van je provider. :-) En zorgen dat je maildoos geen openrelay meer is.

http://www.ordb.org/lookup/rbls/?host=194.229.255.194 Hier sta je dus op

Nu niet meer geloof ik. HUH vaag

[ Voor 8% gewijzigd door raymonvdm op 19-07-2003 04:13 ]

[MikeN]

raymonvdm schreef op 19 July 2003 @ 04:10:
Ze blokken geen mail voor klanten maar spammers.

Als je even de beschrijving leest van de rbl waar het IP adres opstaat zie je dat het een "high risk" lijst is, die niet gebruikt moet worden om te blocken. Waarom? Omdat er simpelweg hele ranges (zoals uu.net) geblocked worden ipv specifieke ip's die echt open relays zijn.

[Hans]

XBL gebruiken is ongeveer hetzelfde als port 25 afsluiten voor de buitenwereld. In XBL is zo bizar veel geblocked (de halve aardkloot zo ongeveer) dat het een totaal onbruikbare RBL is.

[igmar]

XBL is slechts een deel van het probleem hier. Met die lijst gaan blocken is zowiezo niet al te snugger. Een tweede probleem is dat steeds meer mensen Worldcom blokkeren, omdat ze grote hoeveelheden spammers hosten en totaal niet aan abuse doen.

Ik zou zelf de keus nemen om een andere ISP te nemen, maar dat is niet voor iedereen een optie.

[Loesje]

Nu zit ik niet zo in het provider-wereldje, maar heb je iets van linkjes om je bewering over Worldcom te staven?

[igmar]

Loesje schreef op 20 July 2003 @ 16:11:
Nu zit ik niet zo in het provider-wereldje, maar heb je iets van linkjes om je bewering over Worldcom te staven?

http://groups.google.com/...640%40psinet-eu-nl&rnum=2

is een van de vele die aangeeft dat UUnet vol met spammers zit, nog maar niet te spreken over het management die duidelijk aangeeft het allemaal prima te vinden.

[Loesje]

Dat er nog steeds zichzelf respecterende providers zijn die spam 'geen probleem' vinden...

[Coen Rosdorff]

raymonvdm schreef op 19 juli 2003 @ 04:10:
Ze blokken geen mail voor klanten maar spammers.

Ze blokken wel email van klanten. Email bestemd VOOR de klant, en dus VAN de klant.

En ik maak graag zelf uit wat spam is, en wat niet.

Dat verhaal van die rusische server komt doordat er een hele vreemde persoon aan de whois info hangt:

code:

person:       Roman V Popov
address:      Company Mega
address:      10/3, Akademichesky str.
address:      634055, Tomsk, Russia
phone:        [phone]
e-mail:       [e-mail]
nic-hdl:      RVP1-RIPE
notify:       [e-mail]
changed:      [e-mail] 19981215
source:       RIPE

Lijkt mij niet correct, en kan/moet UUnet oplossen.

[igmar]

little_soundman schreef op 17 July 2003 @ 15:51:
Makkelijkste oplossing: Gewoon weggaan bij een clue-less provider die wel de klok heeft horen luiden maar niet waar de klepelhangt.

Zomaar ongevraagd mail voor klanten gaan blokkeren adhv lijsten die niet voor dat doel bestaan is echt niet acceptabel.

Lees het verhaal nog maar eens. UUNet blokkeert niet, Zonnet doet dat.

[igmar]

little_soundman schreef op 20 July 2003 @ 22:05:
[...]

Ze blokken wel email van klanten. Email bestemd VOOR de klant, en dus VAN de klant.
En ik maak graag zelf uit wat spam is, en wat niet.

Vertel dat Zonnet. De TS heeft hier weinig aan.

Dat verhaal van die rusische server komt doordat er een hele vreemde persoon aan de whois info hangt:

code:

person:       Roman V Popov
address:      Company Mega
address:      10/3, Akademichesky str.
address:      634055, Tomsk, Russia
phone:        [phone]
e-mail:       [e-mail]
nic-hdl:      RVP1-RIPE
notify:       [e-mail]
changed:      [e-mail] 19981215
source:       RIPE

Lijkt mij niet correct, en kan/moet UUnet oplossen.

En ? Dit lost het probleem van de block niet op.

[Coen Rosdorff]

igmar schreef op 21 July 2003 @ 10:32:
[...]
En ? Dit lost het probleem van de block niet op.

Nee, maar de topic starter zit er schijnbaar nogal mee zoals je in zijn openings post kan lezen.

[igmar]

little_soundman schreef op 22 July 2003 @ 01:31:
Nee, maar de topic starter zit er schijnbaar nogal mee zoals je in zijn openings post kan lezen.

De TS heeft UUNet gekozen, en dat staat garant voor problemen. Dat er ISP's zijn die met XBL blocken is een ander verhaal, maar een andere oplossing als van ISP verhuizen zit er voor de TS niet in.