Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Disclaimer: I do AV/Anti-spam for ~ 250,000 folk. Many of my e-mail addresses are also plastered all over the 'net, so I get plenty of these bounces too.

    Still, from my perspective, mail must *not* get lost. Failure to deliver a message to it's recipient must *always* generate a bounce message (i.e., an SMTP 5xx error).

    Why? Because I don't trust anti-virus software to always do the right thing. I don't trust anti-spam software to always do the right thing. I don't trust *BLs and local block lists to

    • I fail to see how an automated message saying "A message you didn't send to someone you don't know couldn't be delivered" is useful.

      • I fail to see how an automated message saying "A message you didn't send to someone you don't know couldn't be delivered" is useful.

        It's not. And if you've got an algorithm that can determine when to silently drop mail on the floor with no false positives, I'm all ears. But RFC 2821, s4.2.5 is quite clear on an MTA's responsibilities after it accepts a message. I don't think picking and choosing which bits of an RFC to implement is a good idea.

        Yes, 2821 is in need of an update to deal with today's In

        • If you can detect that the message contains a virus, don't send the virus back. If you can detect which virus the message contains, you can tell whether the virus spoofs e-mail addresses. If it does, don't even send a bounce.

          I gather from the fact that so many of these bounce messages say "Your message tested positive for Sobig" that both points are actually possible — and pratical.

          • If you can detect that the message contains a virus, don't send the virus back.

            Doesn't work if you're trying to save cycles for wanted mail, and rejecting messages based on attachment types, or other content (e.g., the presence of web bugs).

            To be specific, consider three sites, A, B, and C. B has the virus, and is sending mail to C, with forged headers that look like it came from A.

            If C refuses to accept the message (SMTP 5xx), it's B that generates the bounce message to A. The mail logs at B shoul

            • Perhaps we're talking about different things. Could you explain the difference between a 5xx rejection and a normal "You sent us a virus!" message? Which does NAV, InterScan, etc... send out? More importantly, does the 5xx show up as regular mail?
              • Perhaps we're talking about different things. Could you explain the difference between a 5xx rejection and a normal "You sent us a virus!" message? Which does NAV, InterScan, etc... send out? More importantly, does the 5xx show up as regular mail?

                The "You sent us a virus" messages are the ones from products like NAV that try to be helpful, while at the same time marketing the product. They're generated by the site that's doing the scanning (so if B is infected, sends a message to C, forged to appear to

                • I get so few of those. :( Most are of the NAV variety.

                  But it doesn't seem anyone's hit upon the simple idea of a mail header:

                  SMTP-Reponse: 554 May contain nuts

                  Different SMTP servers encode their response code in different ways in the body of the mail. That its just more mail that I have to scan and junk. Since the format isn't unambiguous, I'm back to writing rules. :( However, they are significantly easier rules than what NAV and friends are causing me to write.

                  Ideally what I'd want is for server A to tell my SMTP server "Hey, you sent me a virus" in a clear way so that my SMTP server can throw it away before I ever see it. A simple mail header would be nice.

                  For no particular purpose, here's a very small sampling of the transcripts I've been getting that contain "554".

                  ----- Transcript of session follows -----
                  ... while talking to smtp-bounce.mac.com.:
                  >>> DATA
                  <<< 550 5.1.1 unknown or illegal alias: 6bcb192e-5b33-11d6-aee8-0003937ae4da@mac
                  .com
                  550 5.1.1 <6BCB192E-5B33-11D6-AEE8-0003937AE4DA@mac.com>... User unknown
                  <<< 554 5.5.0 No recipients have been specified.

                  ----- Transcript of session follows -----
                  ... while talking to ms-mta-01-fn.nyroc.rr.com.:
                  >>> DATA
                  <<< 550 5.1.1 unknown or illegal alias: jc@rochester.rr.com
                  550 5.1.1 <jc@rochester.rr.com>... User unknown
                  <<< 554 5.5.0 No recipients have been specified.

                  ----- Transcript of session follows -----
                  ... while talking to ams-msg-core-1.cisco.com.:
                  >>> DATA
                  <<< 552 5.0.0 SOBIG.F Virus outbreak - temp fix
                  554 5.0.0 Service unavailable

                  ----- Transcript of session follows -----
                  ... while talking to filter-a.smig.net.:
                  >>> DATA
                  <<< 554 5.6.0 Message rejected because it contains one or more viruses
                  554 5.0.0 Service unavailable

                  ----- Transcript of session follows -----
                  ... while talking to ams-msg-core-1.cisco.com.:
                  >>> DATA
                  <<< 552 5.0.0 SOBIG.F Virus outbreak - temp fix
                  554 5.0.0 Service unavailable

                  ----- Transcript of session follows -----
                  ... while talking to [172.31.255.102]:
                  >>> RCPT To:<scarrie@maginfo.fr>
                  <<< 554 Mail for scarrie@maginfo.fr rejected for policy reasons.
                  554 <scarrie@maginfo.fr>... Service unavailable

                  ----- Transcript of session follows -----
                  ... while talking to syd-msg-core-1.cisco.com.:
                  >>> DATA
                  <<< 552 5.0.0 SOBIG.F Virus outbreak - temp fix
                  554 5.0.0 Service unavailable

                  ----- Transcript of session follows -----

                  ANTIVIRUS SYSTEM FOUND VIRUSES

                  From: <schwern@pobox.com>
                  Subject: Re: Details

                  dfh7RCTwv16840/text    infected: I-Worm.Sobig.f.txt
                  dfh7RCTwv16840/document_9446.pif    infected: I-Worm.Sobig.f

                  554 5.6.0 Viruses were detected
                  501 5.6.0 Data format error

                  ----- Transcript of session follows -----

                  !!! POZOR !!! POSTOVNI SERVER MU NALEZL VE VASI POSTE VIRUS.
                  !!! POZOR !!! V PRILOZE MATE HLAVICKU MAILU PRO PRIPADNY
                  !!! POZOR !!! KONTAKT NA ODESILATELE

                  ANTIVIRUS SYSTEM FOUND VIRUSES

                  From:    <schwern@pobox.com>
                  To:      <yeti@physics.muni.cz>
                  Subject: Re: Details

                  dfh7RCnaa7031411    archive: Mail
                  dfh7RCnaa7031411/text    infected: I-Worm.Sobig.f.txt
                  dfh7RCnaa7031411/movie0045.pif    infected: I-Worm.Sobig.f

                  This message contain viruses. Virus was detected
                  with Antiviral Toolkit Pro from http://www.avp.ru.

                  554 5.6.0 Viruses were detected
                  501 5.6.0 Data format error

                  ----- Transcript of session follows -----
                  ... while talking to ms-mta-02-fn.nyroc.rr.com.:
                  >>> DATA
                  <<< 550 5.1.1 unknown or illegal alias: jc@rochester.rr.com
                  550 5.1.1 <jc@rochester.rr.com>... User unknown
                  <<< 554 5.5.0 No recipients have been specified.