Hurricane Katrina communication failures
http://www.washingtonpost.com/wp-dyn/content/article/2005/12/09/AR2005120902039.html During Katrina, virtually every system failed: Internet communications, radio transmissions, cell phones, even backup gear such as satellite phones handed out by federal relief workers after the storm. Even when the equipment worked, officials from different agencies and jurisdictions could not talk with one another. Their radios were simply not compatible.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
This is pointless argument, please stop There are those who think they are right in spamming people with reports of a virus they didn't send and the rest of the planet who think they are mad and wish they'd get a clue. As the recipient of the DSN is _always_ the best judge whether the DSN was sent to a forged return-path, why not take advantage of that superior knowledge? because that superior knowledge has already thrown them all away without looking any slight chance of one being valid is wasted If the AV systems that know they are dealing with forged senders, which they do, just dropped them then the volume of potentially valid ones may be low enough that we wouldn't just bin them all If you make it hard we will ignore it. brandon
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
Robert, sorry I missed the full conversation, and don't have time to read the whole thread, but based on your mail alone a few words of agreement... Please remember people.. RFC 2821 states explicitly that once the receiving server has issued a 250 Ok to the end-of-data command, the receiving server has accepted responsibility for either delivering the message or notifying the sender that it has been unable to deliver. RFC2821 also says that a message MUST NOT be dropped for trivial reasons such as lack of storage space for the message. To that end is a detected virus/trajan/malware/phishing scam etc... a trivial reason to drop the message? Personally I believe that not trivial means not unless the entire server crashes and disks fry etc... To that end I am a firm believer that malware messages SHOULD BE rejected at the end of the data command (which is why I have gone to great lengths to ensure this happens at $employer, and at SORBS).. Failure to have the resources available to perform the virus scanning will result in the messages being delivered to the recipient as a broken message (attachment stripped). There is certainly NO EXCUSE for ANYONE to bounce virus warning messages to ANY user whether local or remote, particularly when the anti virus software will identify the virus and the virus is KNOWN to forge the sender address. As such anyone bouncing large numbers virus warning messages are game for having their servers blocked, and I will not apologise to anyone getting caught by a SORBS automated spamtrap getting a virus warning message (though I will remove them promptly when notified of such an entry). Regards, Mat
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Sat, 10 Dec 2005, Matthew Sullivan wrote: Please remember people.. RFC 2821 states explicitly that once the receiving server has issued a 250 Ok to the end-of-data command, the receiving server has accepted responsibility for either delivering the message or notifying the sender that it has been unable to deliver. RFC2821 also says that a message MUST NOT be dropped for trivial reasons such as lack of storage space for the message. To that end is a detected virus/trajan/malware/phishing scam etc... a trivial reason to drop the message? Personally I believe that not trivial means not unless the entire server crashes and disks fry etc... To that end I am a firm believer that malware messages SHOULD BE rejected at the end of the data command rfc2821 was written prior to this problem we should also take the rfc in context and differentiate between email sent between individuals for which the responsibility applies, and email generated by systems (spam, virus bounces) in which we the providers carry some responsibility to drop them (okay, it would be better if they didnt exist in the first place, but thats not reality) if they can be identified in the best interests of the user to not do this is like saying we have a responsibility to ensure end to end delivery of packets in a DoS attack just because the rules governing routing and ip stacks dont explicitly cover the use of sinks and filters. Steve
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
Date: Fri, 9 Dec 2005 15:08:49 -0800 From: Douglas Otis [EMAIL PROTECTED] Subject: Re: SMTP store and forward requires DSN for integrity On Dec 9, 2005, at 1:12 PM, Todd Vierling wrote: [ ... ] I have not requested the virus warnings (unsolicited), they are being sent via an automated trigger (bulk, by extension of the viruses also being bulk), and they are e-mail -- UBE by definition. Whether they are also formatted as DSNs or delivered like DSNs doesn't take away their UBE status. This is a third-party acting in good faith, It's amazing Mike, can you pass me that crack-pipe ! *any* anti-virus vendor has not only signatures of a specific virus but also a good understanding of what the virus does and how it spreads. If the vendor doesn't, well, they'd better retire from the AV business, because as a vendor they should be able to tell me that. (you know, me customer, you vendor, I give money for features I want) If you want to send DSN's telling people they send out a virus, do so only for viruses which are known *not* to forge or even better, which don't have any SMTP engines of their own. Well, how many of those still wander round ? And how many of those can be found by *outbound* scanning on mailservers at the originating party ? [ ... ] Where do you draw the line, as AV filtering is not the only source of a spoofed DSN problem? Right now dumb AV filtering is akin to a Smurf amplifier. Essentially the AV vendors are DDoS'ing each and every mailserver out there. Great, now a little question, why not inform the recipient of the mails that the AV solution stopped another virus heading their way ? Would be great advertising, see Mr CIO, you have 500 new mails in the last hour, 490 are about how our mailserver stopped all them viruses ! Last month alone, my Spam folder (at work) counted over 80% AV mails. Guess how large that folder has become because of that ? I've jumped from around 1GB normally up to almost 3GB. That jump can be attributed to AV filters everywhere. You'd almost think the AV vendors have a rather large stock in bandwith and storage providers. [ ... ] In this case however, it is in keeping with a general expectation that a DSNs will be sent when a message can not be delivered. If this party wanted to save costs, they would toss the DSN. Save costs ? Sure I wanna save costs. And mind you the most expense isn't in the storage for e-mail for my end users, it's in the cost of me making sure we don't get blacklisted by every other selfrespecting mailserver in the world. Hence we drop virus mails, we log them, and the *recipients* can get a mail telling them a virus was stopped. However we put that into a seperate IMAP folder and not in the INBOX. There's no need to Spam both sender and recipient. The recipient on our end can check to see if a message towards them was stopped if they were expecting something. Now viruses aren't the only scourge, I know, but the AV vendors are hard underway to destroy e-mail as a communications tool, where previously this was the doing of Spammers. I don't think any AV vendor would consider themselves more evil then Spammers, Phishers or scriptkiddies, but they will be if they don't act more responsibly. Regards, JP Velders
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
From [EMAIL PROTECTED] Sat Dec 10 06:58:38 2005 Date: Sat, 10 Dec 2005 12:57:34 + (GMT) From: Stephen J. Wilcox [EMAIL PROTECTED] Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) On Sat, 10 Dec 2005, Matthew Sullivan wrote: Please remember people.. RFC 2821 states explicitly that once the receiving server has issued a 250 Ok to the end-of-data command, the receiving server has accepted responsibility for either delivering the message or notifying the sender that it has been unable to deliver. RFC2821 also says that a message MUST NOT be dropped for trivial reasons such as lack of storage space for the message. To that end is a detected virus/trajan/malware/phishing scam etc... a trivial reason to drop the message? Personally I believe that not trivial means not unless the entire server crashes and disks fry etc... To that end I am a firm believer that malware messages SHOULD BE rejected at the end of the data command rfc2821 was written prior to this problem Systems which 'silently discard' virus-infected messages for policy reasons are not in violation of RFC 2821, nor even the obseleted 821. Delivery of a message does NOT require that the message hit a person's in box. Trivial proof: mail to an 'autoresponder'. 'Delivery' of any message is handled in accordance with 'policy' established at the receiving site. If policy dictates that that message be routed to the bit-bucket, rather than to the user's mailbox, that message *IS* considered 'delivered', within the context of RFC 2821. we should also take the rfc in context and differentiate between email sent between individuals for which the responsibility applies, and email generated by systems (spam, virus bounces) in which we the providers carry some responsibility to drop them (okay, it would be better if they didnt exist in the first place, but thats not reality) if they can be identified in the best interests of the user to not do this is like saying we have a responsibility to ensure end to end delivery of packets in a DoS attack just because the rules governing routing and ip stacks dont explicitly cover the use of sinks and filters. Steve
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, 9 Dec 2005, Douglas Otis wrote: When there is some percentage of false-positive detection, I'm *loving* your crack-induced comedy. Troll it up, bay-bee! Show me the false positive rate. If you can prove any site with more than 0.1% FP on malware detection with any off the shelf product, I'll give you a magic cookie. Abusing the rest of the world does *not* justify saving the single, incredibly improbable, FP in comparison. Abuse is abuse; it's not up to millions of receiving hosts to put up with the abuse happily because of your hallucinogenic false positive. Put down the crackpipe and walk away from the keyboard before you say something else your employer will regret. (These might be your opinions, but it's telling if a company continues to employ someone who doesn't understand said company's market at all, in spite of any disclaimers.) -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Sat, 2005-12-10 at 15:40 +0100, JP Velders wrote: *any* anti-virus vendor has not only signatures of a specific virus but also a good understanding of what the virus does and how it spreads. If the vendor doesn't, well, they'd better retire from the AV business, because as a vendor they should be able to tell me that. (you know, me customer, you vendor, I give money for features I want) With the high prevalence of viruses having a forged return-path, the concern is largely about _false_ detections. These are not actual numbers, but perhaps more realistic than figures suggested previously. Imagine the false positive error rate for an email AV filter runs about 1 in 1000 malwares. While indeed this may not be a tragedy having a few valid emails lost without notice in an AV effort, this loss is not required when valid DSN recognition is deployed. The AV filter then bounce technique has been used for many years, where DSNs must be filtered at the DSN recipient. Rather than seemingly fruitless complaining, automate this process to refuse invalid DSNs before the data phase, and prevent the DoS effects. This automation will also recover the valid 1 in 1000 DSNs. This BATV automation would also ensure no DSNs with forged return-paths, created at any point where acceptance criteria differs between MTAs, will be accepted before the data phase. BATV should be almost as effective as a DNS-BL. You can even use automate BATV refusals by others to add to your own temp BL. Now viruses aren't the only scourge, I know, but the AV vendors are hard underway to destroy e-mail as a communications tool, where previously this was the doing of Spammers. I don't think any AV vendor would consider themselves more evil then Spammers, Phishers or scriptkiddies, but they will be if they don't act more responsibly. Consider forged DSN automated detection before data phase as an opportunity to improve upon the integrity of email delivery, while also preventing the DoS situation. BATV can be implemented where the implementer sees the benefits immediately. When widely deployed, the back-scatter problem dissolves, as forged DSNs will not serve as an exploit, but rather acts as a trap. Once again valid DSNs regain their rightful respectability as needed in any store and forward system. -Doug
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Sat, 10 Dec 2005, Douglas Otis wrote: With the high prevalence of viruses having a forged return-path, the concern is largely about _false_ detections. These are not actual numbers, but perhaps more realistic than figures suggested previously. Imagine the false positive error rate for an email AV filter runs about 1 in 1000 malwares. While indeed this may not be a tragedy having a few valid emails lost without notice in an AV effort, this loss is not required when valid DSN recognition is deployed. The loss is also not required when virus/malware scanning is done during the SMTP conversation. Google for QHPSI. Messages don't have to disappear and bogus DSNs don't have to be sent. People just need to modernize their MTAs. The AV filter then bounce technique has been used for many years, where DSNs must be filtered at the DSN recipient. Rather than seemingly Like many other things on the internet, just because it's been in place for many years doesn't mean its a good idea or still a viable system. will also recover the valid 1 in 1000 DSNs. This BATV automation would also ensure no DSNs with forged return-paths, created at any point where acceptance criteria differs between MTAs, will be accepted before the data phase. BATV should be almost as effective as a DNS-BL. You can even use automate BATV refusals by others to add to your own temp BL. That still leaves our (the people not sending bogus DSNs) systems having to do lots of work (validating signitures) to decide how to handle DSNs that should never have been sent. Interesting that you should mention DNSBLs. I've seen people asking for DNSBLs of bogus DSN senders for years. I hope the integration of AV filtering and MTAs will improve before we see widespread use of bogus DSN sender DNSBLs. Unfortunately, for some people, experiencing pain is the only way they can be convinced to clean up their problems. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Fri, Dec 09, 2005 at 09:03:10AM -0800, Douglas Otis wrote: There is a solution you can implement now that gets rid of these tens of thousands of virus and abuse laden DSNs you see every day before the data phase. BATV is not a solution. It's a band-aid. It fails to address the underlying problem and instead focuses on merely trying to cope with one of the symptoms of that problem. And it also places the burden on the people who are NOT PART OF THE PROBLEM, and who therefore should not be the ones tasked with solving it. The solution isn't to try to figure out what to do with UBE generated by broken mail systems, broken anti-spam systems, broken anti-virus systems, and the like; the solution is to fix those systems so that they don't generate it. The best place to stop spam is as near its source as possible goes the maxim, and THE best place IS its source. This is not hard. It's been discussed at extraordinary length on spam-l, and one of the outcomes of those discussions is that while there are some edge cases that can be tough (depending on mail system architecture) those are a tiny minority, and the overwhelming majority can be dealt with quickly and easily. I would strongly suggest that anyone wishing to continue this discussion (a) read the archived discussion thoroughly and (b) take it up on spam-l, where it's probably more appropriate and where huge amounts of relevant clue exist among participants. ---Rsk
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Wed, Dec 07, 2005 at 02:15:00PM -0800, Douglas Otis wrote: When auth fails, one knows *right then* c/o an SMTP reject. No bounce is necessary. This assumes all messages are rejected within the SMTP session. Yes, exactly and the point several of us have been making is that this is (a) easy (well, provided you're using a quality MTA; if not, then switch to one) (b) running a sane mail system (c) fast (d) resource-friendly and (e) most important of all, the _only_ way to avoid sending UBE in response to forgeries (which are not going away any time soon or quite possibly ever). (Please note: there are no exceptions to the UBE specification for DSNs. If DSNs are: - sent to forged senders (thus unsolicited) - in bulk (thus bulk) - via email (thus email) then they are UBE, which is THE definition of spam -- and which deliberately omits any mention of content, purpose or other things that are irrelevant to the spam/not-spam question.) ---Rsk
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
MS Date: Sat, 10 Dec 2005 22:54:24 +1100 MS From: Matthew Sullivan MS RFC 2821 states explicitly that once the receiving server has issued a 250 MS Ok to the end-of-data command, the receiving server has accepted MS responsibility for either delivering the message or notifying the sender MS that it has been unable to deliver. RFC2821 also says that a message MUST And RFC 1034/1035 (I forget which) specifies an RD bit which, in reality, is rather useless. Following RFCs is good for compatibility. However, RFCs are hardly infallible word from on high. Sometimes they require revisiting and revision. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
DO Date: Fri, 9 Dec 2005 15:08:49 -0800 DO From: Douglas Otis DO This is a third-party acting in good faith, albeit performing a check better DO done within the session. In your view, there is less concern about delivery DO integrity, and so related DSNs should be tossed. Being done within the DO session would be ideal, of course. When their architecture does not support Let's use some hyperbole: Say that the latest megaworm chucks out spam at speeds resembling SQL Slammer. The return-path specified is your email address. Millions of MXes send _you_ bogus DSNs in good faith. Is this acceptable? If not, where do you draw the line -- and does that line apply to others, too? Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Sat, 10 Dec 2005, Edward B. Dreger wrote: Let's use some hyperbole: Say that the latest megaworm chucks out spam at speeds resembling SQL Slammer. The return-path specified is your email address. Millions of MXes send _you_ bogus DSNs in good faith. That's not exactly hyperbole. My antivirus-spew counter on my 9-user SMTP server rolled past 1M more than a year ago. Per incident, it isn't more than 1M; moire like ~50k, but that is still well beyond DDoS level. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: SMTP store and forward requires DSN for integrity
JP == JP Velders [EMAIL PROTECTED] writes: JP Right now dumb AV filtering is akin to a Smurf amplifier. Good analogy. I would extend it by pointing out that dumb AV filtering is actually only a part of the general backscatter problem. The existence of BATV isn't an excuse for mail system operators to ignore the backscatter problem any more than the existence of stateful firewalls is an excuse for people to run smurf amplifiers. Right now, unless you are a large provider or corporate, or unless your mail system is massively over-engineered, any spammer can, at any time, drown you in bounces (30 million SMTP transactions in response to one spam run has been observed in practice). BATV doesn't help you if the problem is SMTP transaction volume, any more than a firewall will help you cope with a saturated network link. It is, in my view, the responsibility of every mail system operator to design and operate their systems in such a way as to minimize the impact of backscatter on innocent third parties. This is not to say that DSNs should not be sent (because that would indeed cause an integrity problem) but that they should be avoided. Forged virus backscatter is just one of the more trivial examples (trivial because much of it is caused by A/V systems that _know_ they should not be doing it); there are many other sources of backscatter that are not specific to viruses, most of which can easily be controlled by proper feedback to the SMTP server (e.g. accounts which go over quota and _stay_ that way should be set to reject traffic at SMTP time, so that they don't become continuous sources of backscatter). -- Andrew, Supernews http://www.supernews.com
Re: SMTP store and forward requires DSN for integrity
On Sat, 2005-12-10 at 17:37 +, Andrew - Supernews wrote: BATV doesn't help you if the problem is SMTP transaction volume, any more than a firewall will help you cope with a saturated network link. I agree with most of your statements. AV filters should be done within the session when possible, etc. Your statement regarding BATV is not correct however. There are two ways BATV reduces SMTP transaction volume when dealing with forged DSNs. Previous return-path and real email-address: [EMAIL PROTECTED] Is transformed by BATV with a private tag into: prvs=fred/KDDDSS@example.com S: 220 mail.example.com ESMTP Ready C: EHLO fred.example.com S: 250-mail.example.com Hello fred.example.com S: 250-ENHANCEDSTATUSCODES S: 250-PIPELINING S: 250-8BITMIME S: 250-SIZE 2000 S: 250-DSN S: 250-ETRN S: 250-AUTH PLAIN LOGIN S: 250-STARTTLS S: 250-DELIVERBY S: 250 HELP C: MAIL FROM: S: 250 2.1.0 ... Sender ok C: RCPT TO: [EMAIL PROTECTED] S: 550 5.1.1 fred.example.com... User unknown C: QUIT When the MAIL FROM is , the only valid RCPT TO would be a BATV address such as: ... C: RCPT TO: prvs=fred/[EMAIL PROTECTED] S: 250 2.1.5 prvs=fred/[EMAIL PROTECTED]... Recipient ok C: DATA S: 354 Enter mail, end with . on a line by itself C: This is a notification you sent a virus to joe.tld at ... C: Blah, Blah, Blah, and by the way, here is the virus. ... C: ... C: . S: 250 2.0.0 234fls89056789 Message accepted for delivery C: QUIT The BATV is a few lines of code that adds a private tag with a time limit set in days. BATV helps dramatically by eliminating the DATA phase and all that is involved in handling messages. In addition, once BATV becomes more widely deployed, the DSN refusal offers an alert about accepting more such messages from that IP address. BATV will make forged DSNs a thing of the past, irrespective of where a recipient list is checked, an AV or SPAM filter is added, etc. -Doug
Re: SMTP store and forward requires DSN for integrity
On Sat, 10 Dec 2005, Douglas Otis wrote: BATV will make forged DSNs a thing of the past, irrespective of where a recipient list is checked, an AV or SPAM filter is added, etc. Stop plugging a recipient-side cost-shift scheme that you're directly involved with as some sort of panacea. BATV has benefits, as do other schemes, but you're still fixated on it as being the end-all, be-all of forgery prevention -- by making third parties do the dirty work and letting the instigators off the hook. By putting the costs on the shoulders of third parties, you're putting yourself squarely on the side of the spewing hosts, and being as ignorant as the admins running the anti-malware products on those hosts. For shame. Until you get the point that you're putting the burden on people that have nothing to do with the problem that started this long thread (anti-malware notices to forged senders), and your first priority should be stopping that spew at the source BEFORE asking uninvolved third parties to help, you're going to continue to look like the self-absorbed crack smoker you've made yourself out to be. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: SMTP store and forward requires DSN for integrity
From [EMAIL PROTECTED] Sat Dec 10 15:55:48 2005 Subject: Re: SMTP store and forward requires DSN for integrity From: Douglas Otis [EMAIL PROTECTED] To: Andrew - Supernews [EMAIL PROTECTED] Cc: nanog@merit.edu Date: Sat, 10 Dec 2005 13:54:37 -0800 On Sat, 2005-12-10 at 17:37 +, Andrew - Supernews wrote: BATV doesn't help you if the problem is SMTP transaction volume, any more than a firewall will help you cope with a saturated network link. I agree with most of your statements. AV filters should be done within the session when possible, etc. Your statement regarding BATV is not correct however. There are two ways BATV reduces SMTP transaction volume when dealing with forged DSNs. Previous return-path and real email-address: [EMAIL PROTECTED] Is transformed by BATV with a private tag into: prvs=fred/KDDDSS@example.com S: 220 mail.example.com ESMTP Ready C: EHLO fred.example.com S: 250-mail.example.com Hello fred.example.com S: 250-ENHANCEDSTATUSCODES S: 250-PIPELINING S: 250-8BITMIME S: 250-SIZE 2000 S: 250-DSN S: 250-ETRN S: 250-AUTH PLAIN LOGIN S: 250-STARTTLS S: 250-DELIVERBY S: 250 HELP C: MAIL FROM: S: 250 2.1.0 ... Sender ok C: RCPT TO: [EMAIL PROTECTED] S: 550 5.1.1 fred.example.com... User unknown C: QUIT When the MAIL FROM is , the only valid RCPT TO would be a BATV address such as: ... C: RCPT TO: prvs=fred/[EMAIL PROTECTED] S: 250 2.1.5 prvs=fred/[EMAIL PROTECTED]... Recipient ok C: DATA S: 354 Enter mail, end with . on a line by itself C: This is a notification you sent a virus to joe.tld at ... C: Blah, Blah, Blah, and by the way, here is the virus. ... C: ... C: . S: 250 2.0.0 234fls89056789 Message accepted for delivery C: QUIT The BATV is a few lines of code that adds a private tag with a time limit set in days. BATV helps dramatically by eliminating the DATA phase and all that is involved in handling messages. In addition, once BATV becomes more widely deployed, the DSN refusal offers an alert about accepting more such messages from that IP address. BATV will make forged DSNs a thing of the past, irrespective of where a recipient list is checked, an AV or SPAM filter is added, etc. TWO FACED, DOUBLE STANDARD, SPEAKS WITH FORKED TONGUE. BATV has the risk of false-positive detection of an 'invalid' DSN. All it takes is a remote mail system that keeps 'trying' to deliver to a tempfailing address for _longer_ than the lifetime of that 'private tag'. Congratulations, you have just blocked a *valid* DSN failure notice. Your approach has just demonstrably 'impaired the integrity of the email system'. Strange, isn't it, that your solution will do exactly what you insist is utterly unacceptable behavior for any other approach. Remember, the putative sender (the person, not the software) is the best judge of whether or not that NDR is a delayed response to a message they sent. Why not take advantage of that superior knowledge?
Re: SMTP store and forward requires DSN for integrity
From [EMAIL PROTECTED] Sat Dec 10 16:56:38 2005 Date: Sat, 10 Dec 2005 17:55:38 -0500 (Eastern Standard Time) From: Todd Vierling [EMAIL PROTECTED] To: nanog@merit.edu Subject: Re: SMTP store and forward requires DSN for integrity On Sat, 10 Dec 2005, Douglas Otis wrote: BATV will make forged DSNs a thing of the past, irrespective of where a recipient list is checked, an AV or SPAM filter is added, etc. Stop plugging a recipient-side cost-shift scheme that you're directly involved with as some sort of panacea. BATV has benefits, as do other schemes, but you're still fixated on it as being the end-all, be-all of forgery prevention -- by making third parties do the dirty work and letting the instigators off the hook. By putting the costs on the shoulders of third parties, you're putting yourself squarely on the side of the spewing hosts, and being as ignorant as the admins running the anti-malware products on those hosts. For shame. I recommend to all a review of the Rules of Spam. Rule #1, in particular. Specifically the Lexical Contradiciton and Sharp's Corollary. We seem to have yet another example for the 'rules-keeper's refrain'. *sigh* Considering the source of _this_ demonstration, one can only despair -- what possible chance is there for things to 'get better', when one of the putatively 'good guys' espouses that kind of double-think?
Re: SMTP store and forward requires DSN for integrity
On Sat, 2005-12-10 at 17:51 -0600, Robert Bonomi wrote: BATV has the risk of false-positive detection of an 'invalid' DSN. All it takes is a remote mail system that keeps 'trying' to deliver to a tempfailing address for _longer_ than the lifetime of that 'private tag'. Congratulations, you have just blocked a *valid* DSN failure notice. The expiry period of the tag is determined by the MSA of the message. Setting this period for more than 5 days should extend beyond retry efforts, so make it ten days. Your approach has just demonstrably 'impaired the integrity of the email system'. The tag only needs a reasonable expiry controlled by the MSA. Exhaustion of delivery retry are getting shorter. Remember, the putative sender (the person, not the software) is the best judge of whether or not that NDR is a delayed response to a message they sent. Why not take advantage of that superior knowledge? Tagging of the return-path address would be transparent to the author. They would not even see this change, nor would they ever see any DSNs for messages they did not send. They would be protected from bounced malware and other forms of abuse using this avenue of entry. -Doug
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
mary wrote: mta test anyone? [snip Eicar signature] You didn't attach it. If you had, I'm pretty sure Exim (running an ACL plugged into ClamAV) would have caught it before it got to my Inbox. Clam detects Eicar just fine. : What you did was include it inline in a text/plain MIME part in your message, where it isn't likely that it could do any harm even if it *was* a real virus. -- Steve Sobol, Professional Geek 888-480-4638 PGP: 0xE3AE35ED Company website: http://JustThe.net/ Personal blog, resume, portfolio: http://SteveSobol.com/ E: [EMAIL PROTECTED] Snail: 22674 Motnocab Road, Apple Valley, CA 92307
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
[snip Eicar signature] You didn't attach it. If you had, I'm pretty sure Exim (running an ACL plugged into ClamAV) would have caught it before it got to my Inbox. Clam detects Eicar just fine. : :) I did receive two your message contains a virus replies. One was a Panda GateDefender, sounds Windowsish. What you did was include it inline in a text/plain MIME part in your message, where it isn't likely that it could do any harm even if it *was* a real virus. nods real harm/mass traffic not intended -m
