RE: Distributed spam-based DoS in progress

From: Dave Hart (davehart@davehart.com)
Date: 02/19/03

  • Next message: Steve Drees: "RE: Distributed spam-based DoS in progress"
    Date: Wed, 19 Feb 2003 07:26:37 -0000
    From: "Dave Hart" <davehart@davehart.com>
    To: "Incidents Mailing List" <incidents@securityfocus.com>
    
    

    Hugo van der Kooij quotes two different sections of current SMTP RFC in
    response to my challenge to cite where in the RFC the behavior he
    described is documented. He does not in fact find any such citation,
    and instead changes the subject by claiming the _real_ problem is that
    no incoming MX server should ever accept mail that will eventually
    bounce. There are many reasons why such configurations are useful.
    Examples:

    A. Backup MX servers provided by third parties routinely accept all
    mail for domains they service for inbound relay. Backup MX is not
    really interesting until there are brief outages for the primary MX, so
    in practice the backup servers are not going to have enough information
    to bounce invalid recipients.
    B. SMTP-based inbound antivirus scanners and spam scanners such as
    SpamAssassin in front (SMTP-wise) of a Microsoft Exchange server. Here
    because the front-end scanner is backend receiving mailer-neutral it is
    often unaware of which recipient addresses are valid.
    C. Prevention of trivial probing for valid email addresses. Spammers
    have a practice of hitting a mailserver with "war-dialed" random
    recipient addresses using RCPT without ever actually sending mail. This
    scanning stays below the radar of many administrators, who often do not
    log a RCPT with no successful DATA/BDAT to complete the transaction.

    Getting back to the original message of this thread, there is nothing
    "broken" about the SMTP server behavior observed by the presumptive DoS
    victim. I welcome evidence from relevant RFCs that contradict me on
    this point.

    Regards,
    Dave Hart

    ----------------------------------------------------------------------------
    This list is provided by the SecurityFocus ARIS analyzer service.
    For more information on this free incident handling, management
    and tracking system please see: http://aris.securityfocus.com



    Relevant Pages

    • Re: Little C socket help required
      ... you will try to receive 99 packets from the server before sending ... Is that what the SMTP RFC specified??? ...
      (comp.unix.programmer)
    • Re: Little C socket help required
      ... you will try to receive 99 packets from the server before sending ... Is that what the SMTP RFC specified??? ...
      (comp.os.linux.development.apps)
    • Re: virus mail ignores MX?
      ... are not very clear about RFCs, even if the RFC had specified a MUST, ... an intelligent guess that a backup MX server is probably not as well ... >> When I see virus mail header, ... >> pen testing experience in our state of the art hacking lab. ...
      (Security-Basics)
    • Re: FtpWebRequest Passive Mode Problem
      ... Sorry about the error in my assertion that the port is not necessarily ... changed by the server. ... RFC and some articles on NAT/Proxy configurations, ... When using an ftpd behind a NAT ...
      (microsoft.public.dotnet.framework)
    • Re: UTF8 beim FTP-Protokoll
      ... Der von Dir gelinkte Draft vom RFC ist doch ganz eindeutig ... | feature to determine if a server supports ... ueberprueft ob bei FEAT ein UTF8 ...
      (de.comp.lang.c)