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.

How do you amplify a public service announcement? 21 Comments More | Login | Reply /

 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 always be 100% accurate.

    Silently dropping mail on the floor just isn't an option. Because sooner or later you'll drop something important.

    N

    • 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

        • > I don't think picking and choosing which bits of an RFC to implement is a good idea

          I do. Please feel free to not do things that are obviously broken. It wasn't that long ago that an RFC called for all SMTP servers to be open relays.

        • 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

            • If C accepted the message and silently refused to deilver it then why would B retry? That makes no sense.

              As Schwern pointed out the anti-virus vendors do know which virus is which and they do know which ones spoof sender addresses so of course they shouldn't bounce those ones back to the 'sender'. They should simply say '200 Hmm Yummy' and do nothing more.

              But I have an even simpler rule ... Never generate a bounce response when a virus is detected. Any virus. Ever. By all means have your virus scan

              • Never generate a bounce response when a virus is detected. Any virus.

                As I say -- doesn't work if you're bouncing because of something else in the message (e.g., an attachment type that you don't want to see -- .exe, .pif, etc). This is much simpler to check for than doing a full virus scan, so it runs faster, so it's a better use of resources.

                By all means have your virus scanning software alert the recipient - as a human being, they can eyeball the sender address and decide whether they want to do anyt

                • As I say -- doesn't work if you're bouncing because of something else in the message (e.g., ... .exe, .pif, etc).

                  Nonsense. You are treating messages with those file types as if they contained a virus. So the rule still stands don't bounce it, drop it.

                  If your SMTP server makes a quantitative decision that it can't handle the message (eg: unknown user or out of disk space) then by all means bounce it. On the other hand if your server examines the contents of the message and makes a qualitative decisi

                  • Nonsense. You are treating messages with those file types as if they contained a virus. So the rule still stands don't bounce it, drop it.

                    Not true. It's being treated as 'content not wanted'. There's a large amount of content that's not wanted, and 'has a virus' is just a subset of it. And on a typical day, virus infected content is a tiny fraction of the stuff that gets 5xx'd.

                    If your SMTP server makes a quantitative decision that it can't handle the message (eg: unknown user or out of disk space)

                • This is much simpler to check for than doing a full virus scan, so it runs faster, so it's a better use of resources.

                  Randomly send bounce messages to random e-mail addresses 10% of the time. Don't bother scanning messages. That should keep your system almost as efficient as possible, at the completely ignorable expense of everyone else on the Internet.

                  I don't care if the RFC was handed down on stone tables from Jon Postel. If a bad guy says "Harass innocent people!" and your system does, it's broke

                • As I say -- doesn't work if you're bouncing because of something else in the message (e.g., an attachment type that you don't want to see -- .exe, .pif, etc). This is much simpler to check for than doing a full virus scan, so it runs faster, so it's a better use of resources.

                  A better use of YOUR resources. What about MINE, the poor slob getting flooded?

                  How selfish. You want to employ the world as a giant meat verification system for your overly simplistic virus scanning so you can save a buck!

                  Get

                • Beware of talking cross purposes

                  PS: Railing against AV software that sends helpful notifications back (instead of a 5xx), is a completely different kettle of fish, of course. There's a special level of hell reserved for the authors of Norton AV, which is particularly offensive in this regard.

                  Agree. In the past 24 or so hours, I think I've had 185 "helpful" messages about viruses, versus 21 bounces. So it appears that both sides of this "argument" are right.

                  Personally I'd like

                  • Fuckwits who create AV so
              • As Schwern pointed out
                chromatic and I really are different people. I swear. ;) He says potato, I say potato.
            • 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 serve

            • If C refuses to accept the message (SMTP 5xx), it's B that generates the bounce message to A. The mail logs at B should show (a) a high number of bounces going to A, (b) a large number of 5xx rejections from C. The mail admins at B *should* notice this, and do something about it, and (c) admins at both A and C should notice this, and start complaining to B.

              Oh yeah, I remember the problem I had with this idea. WHAT MAIL ADMIN?!

              I'm it. One guy with a laptop. I'm sure there's lots and lots and lots o

    • You might not trust it to do the right thing, but right now its doing a Very, Very Wrong Thing to such an extent that its effecting the health of the Internet. I don't think you quite understand the magnitude of the problem. I got another 1000 bounce messages overnight. That's absurd.

      With the current setup you're generating a massive quantity of false positives. So much so that I'm now likely to ignore *all* bounce messages. In effect, by flooding the system with false positives you're social enginee

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.