1. Welkom op het onafhankelijke Ziggo Gebruikersforum. Een forum voor en door gebruikers van Ziggo.
    Registreer je gratis om direct zelf berichten te plaatsen en gebruik te maken van extra functies!
    Verberg deze melding

smtp blok

Discussie in 'Internet - Email' gestart door twsgsm, 2 sep 2008.

Niet open voor verdere reacties.
  1. Hoi,

    Waar ik me aan stoor is dat iets gedaan wordt, er geeneens iets gemeld wordt.
    En als je het dan aankaart, vrolijk gemeld wordt dat je zelf de fout maakt.

    Als ik iets fout zou doen, ok, nos problemos.

    Maar tot op heden zie ik niet wat ik fout doe maar ben wel afgesloten.

    Wat ik gewoon hoop is dat een provider zich gewoon sociaal gedraagt.
    Hiermee wil ik niet zeggen dat jij dat niet doet.

    Btw, dit is de gehele mail die terug komt, daar zit het complete bericht gewoon in:


    Return-path: <>
    Received: from checkmail.*******.** ([***.***.***.***])
    by qnt.*******.** with ESMTP; Tue, 30 Sep 2008 19:53:36 +0200
    Received: from localhost (localhost [127.0.0.1])
    by checkmail.*******.** (Postfix) with ESMTP id 6EA4B1341CC
    for <alex@w*******.**>; Tue, 30 Sep 2008 19:55:22 +0200 (CEST)
    Received: from checkmail.*******.** ([127.0.0.1])
    by localhost (checkmail.*******.** [127.0.0.1]) (amavisd-maia, port 10024)
    with ESMTP id 18629-09 for <alex@w*******.**>;
    Tue, 30 Sep 2008 19:55:18 +0200 (CEST)
    Received: from vmx10.multikabel.net (vmx10.multikabel.net [212.127.254.136])
    by checkmail.*******.** (Postfix) with SMTP id 2B41413417F
    for <alex@w*******.**>; Tue, 30 Sep 2008 19:55:18 +0200 (CEST)
    Date: Tue, 30 Sep 2008 19:53:15 +0200 (CEST)
    From: Mail Delivery Subsystem <MAILER-DAEMON@xs4all.nl>
    Message-Id: <200809301753.m8UHrFeh093332@smtp-vbr9.xs4all.nl>
    To: <alex@w*******.**>
    MIME-Version: 1.0
    Content-Type: multipart/report; report-type=delivery-status;
    boundary="m8UHrFeh093332.1222797195/smtp-vbr9.xs4all.nl"
    Subject: Returned mail: see transcript for details
    Auto-Submitted: auto-generated (failure)
    X-MultiKabel-MX-MailScanner-Information: Please go to http://www.multikabel.nl/contact/ for more information
    X-MailScanner-ID: 1KkjPP-0007Ki-0f
    X-MultiKabel-MX-MailScanner: Found to be clean
    X-MultiKabel-MX-MailScanner-SpamCheck:
    X-MailScanner-From:
    X-Virus-Scanned: Maia Mailguard 1.0.2a
    X-Spam-Status: No, hits=4.917 tagged_above=-999 required=5 tests=AWL=2.417,
    BAYES_99=3.5, RCVD_IN_DNSWL_LOW=-1
    X-Spam-Level: ****
    This is a MIME-encapsulated message
    --m8UHrFeh093332.1222797195/smtp-vbr9.xs4all.nl
    The original message was received at Tue, 30 Sep 2008 19:53:15 +0200 (CEST)
    from ***.***.*** [***.***.***.***]
    ----- The following addresses had permanent fatal errors -----
    <raimond@ziggo.nl>
    (reason: 550 <raimond@ziggo.nl>: Recipient address rejected: User unknown in relay recipient table)
    ----- Transcript of session follows -----
    ... while talking to mx1.atwork.nl.:
    >>> DATA
    <<< 550 <raimond@ziggo.nl>: Recipient address rejected: User unknown in relay recipient table
    550 5.1.1 <raimond@ziggo.nl>... User unknown
    <<< 554 Error: no valid recipients
    --m8UHrFeh093332.1222797195/smtp-vbr9.xs4all.nl
    Content-Type: message/delivery-status
    Reporting-MTA: dns; smtp-vbr9.xs4all.nl
    Received-From-MTA: DNS; ***.***.***
    Arrival-Date: Tue, 30 Sep 2008 19:53:15 +0200 (CEST)
    Final-Recipient: RFC822; raimond@ziggo.nl
    Action: failed
    Status: 5.1.1
    Remote-MTA: DNS; mx1.atwork.nl
    Diagnostic-Code: SMTP; 550 <raimond@ziggo.nl>: Recipient address rejected: User unknown in relay recipient table
    Last-Attempt-Date: Tue, 30 Sep 2008 19:53:15 +0200 (CEST)
    --m8UHrFeh093332.1222797195/smtp-vbr9.xs4all.nl
    Content-Type: text/rfc822-headers
    Return-Path: <alex@w*******.**>
    Received: from qnt.*******.** (***.***.*** [***.***.***.***])
    by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id m8UHrFeh093328
    for <raimond@ziggo.nl>; Tue, 30 Sep 2008 19:53:15 +0200 (CEST)
    (envelope-from alex@w*******.**)
    Received: from DOMWARM-MTA by qnt.*******.**
    with Novell_GroupWise; Tue, 30 Sep 2008 19:53:19 +0200
    Message-Id: <48E283AF.ACE3.001E.0@w*******.**>
    X-Mailer: Novell GroupWise Internet Agent 8.0.0
    Date: Tue, 30 Sep 2008 19:53:14 +0200
    From: "alex warmerdam" <alex@w*******.**>
    To: <raimond@ziggo.nl>
    Subject: test
    Mime-Version: 1.0
    Content-Type: multipart/alternative; boundary="=__Part3F16989A.0__="
    X-Virus-Scanned: by XS4ALL Virus Scanner
    --m8UHrFeh093332.1222797195/smtp-vbr9.xs4all.nl--
     
  2. Hi!

    Hele bericht, het is een non deliverable, niet meer niet minder. Kennelijk stuur je je uitgaande mail weg bij xs4all, die pakt um aan en stuurt de bounce weer terug.

    Als je naar eennietbestaandadres@xs4all.nl mailt krijg je hetzelfde terug.
    Of naar sdfsfdsdfsdfsddfdsfdsfgsfsdsdgfgdgd@planet.nl en zovoort.

    Het ligt aan hoe jij je mail afleverd, als je dit doet op een colo machine, en direct afleverd, heb je dit niet. Je relayed je mail via xs4all, die het afleverd, althans, een poging doet. Lukt niet, voilla een bounce terug.

    Works as designed?

    Zo werken de meeste ISP relays, er is geen directe connectie met de mailserver.

    Ik vind het prima om nog dagen door te mailen maar ik heb het idee dat het niks toevoegt aan de discussie. Mischien kan iemand anders nog wat toevoegen ik zelf weet niet hoe ik je moet overtuigen dat het slecht is dat jij als end user bounces stuurt. Want daar ging de hele discussie over, je afsluiting.

    Je mailserver (groupwise in dit geval) pakt alle mails aan, valide rcpt of niet, slikt het bericht in, en spuugt daarna een bounce uit. Dat daar een subtiel verschil in zit tov het voorbeeld wat jij schetst? Wel degelijk. In het geval @ziggo.nl pakt die mailserver NIETS aan. Hij verteld in de sessie met de xs4all mailserver 'bestaat niet, opsouzuh' Dat is echt iets anders al, op kom maar op, aanpakken, oh ken ik toch niet, hier is ie terug, inclusief 2k van de body.

    Subtieler als dit kan ik het echt niet uitleggen, sorry, mischien is dat een tekortkoming. Informeer anders eens bij andere gebruikers met een mailserver hoe ze hier mee omgaan.

    Bye,
    Raymond.
     
  3. Ik heb een eigen mailserver en bounce niets. Is de addressering juist en is de tegenpartij juist geconfigureerd (HELO en client address) dan neem ik de mail aan. Als blijkt dat er iets mis mee is na aanname dan gaat hij direct naar de prullenbak (discarded). Dit is in strijd met rfc 2821, maar diezelfde rfc geeft je geen mogelijkheid om te achterhalen of diegene die aanklopt om mail af te geven wel echt diegene is.
    Zou ik alles bouncen dan kan ik als kwaadwillende gebruiker van allerlei afzenders rotzooi naar je toe kunnen sturen die jij dan netjes gaat bezorgen, dat kan toch ook niet de bedoeling zijn?

    Laat ik nog zeggen dat ik het probleem begrijp, je wilt je conformeren aan de standaarden die voorschrijven dat je op het moment dat je mail aanneemt je er verantwoordelijk voor wordt. Het is echter geen ideale wereld en er wordt op grote schaal misbruik van gemaakt, dus een beetje afwijken van de standaard om wat minder rotzooi over het net te pompen moet mijns inziens kunnen.
     
  4. Het zelfde als Mart, ik bounce ook niets.
    Hoewel het volgends de standaard wel zou moeten, is het met de hoeveelheid spam en de misbruik die hiervan werd gemaakt simpel weg not done om nog te bouncen.

    Als voorbeeld kan ik zeggen dat toen dit nog niet gebruikelijk was, mijn email adres als from adres was (mis/ge)bruikt in een spam run. Met als gevolg dat ik een bounce kreeg van veel niet ingebruik zijnde email adressen. En hier heb ik het niet over 1 of 10 bounces, maar tegen de miljoen bounces. En dat was voor een klein prive servertje toch best wel veel. :sad:

    Misschien dat dit je kan overtuigen en of op weghelpen.
    http://www.spamcop.net/fom-serve/cache/329.html
     
  5. Hier hetzelfde, meerdere malen. Eén keer was het zo erg dat het wel leek op een DDoS aanval, honderden servers die tegelijkertijd mail kwamen bezorgen.
     
Niet open voor verdere reacties.

Deel Deze Pagina