Re: SMTP store and forward requires DSN for integrity
Douglas == Douglas Otis [EMAIL PROTECTED] writes: 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. Douglas Your statement regarding BATV is not correct however. There Douglas are two ways BATV reduces SMTP transaction volume when Douglas dealing with forged DSNs. When you're dealing with 30 million incoming DSNs (this is not a hypothetical figure), being able to reject them all at RCPT TO is not much help. I don't see why I should have to engineer my mail server to handle 5,000 times its expected workload just to accomodate all the bozos who accept-and-bounce, uncontrolled backscatter, sender verification, C/R, and all the other cost-shifting methods out there. -- Andrew, Supernews http://www.supernews.com
Re: SMTP store and forward requires DSN for integrity
- Original Message - From: Douglas Otis [EMAIL PROTECTED] To: Andrew - Supernews [EMAIL PROTECTED] Cc: nanog@merit.edu Sent: Saturday, December 10, 2005 3:54 PM Subject: 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. ... BATV reduces SMTP transaction volume when dealing with forged DSNs. If malware detection systems would not generate a DSN to the originator upon detection in the first place, there would be no need to reduce those transactions as there would be no transactions to reduce. The solution, to me, seems so simple, I must be overlooking something or not comprehending fully what the issue truly is. I thought that the initial problem was with AV mechanisms sending out DSN's to incorrect sender addresses. Please, if I'm so far off base, would someone be so kind as to email me off list and clear this up for me? Honestly Doug, you do realize that your reluctance to stop the problem at the source conveys to everyone on this list the impression that you're only trying to gain support for your proposal don't you? Let's take the malware and av scanners out of the picture for a moment. There was a time, long ago, where malware didn't exist in the email network. At that time, when a message was undeliverable, a DSN was sent to the originator of the message. It happens. Typo's and such. No one complained. Why? Because legitimate email, in order to function requires a valid email address for both parties. Why would they falsify it if they wish to communicate? Now, let's look at it as of today. If someone sends someone a virus, intentionally, it's main purpose is to get to as many systems as it possibly can, as fast as it can to allow the software to propagate before it's detected by AV software. Do you REALLY think that the initial sender wishes to be told that he sent a virus? Do you really believe he/she wishes to even be known or contacted by you in any way? Of course not. Then why do these systems still attempt to send these notices? Well after all logical reasoning has indicated that the sender is forged. The software of today has no way of knowing if the originating system is the actual system that's introduced it into the wild or a carrier. It has no way to validate the email address of the sender. Can BATV correct this? Possibly. But at what cost Doug? How much will it cost them to get the latest and greatest so that they can implement BATV? How much down time will they have to deal with to implement it? Multiply that by the millions of mta's around the globe. Now, you tell me Doug, which is easier for everyone to do? Upgrade/update their mta's around the world or have those few AV detection vendors recode their software? I don't know about you, but if what little information I've found on BATV is current, most folks will have to switch to Exim or NetQmail just to get it to work currently. There's a lot of postfix and sendmail networks out there that may not want to switch. What happens to them? Mike P.
Re: SMTP store and forward requires DSN for integrity
On 12/11/05, Micheal Patterson [EMAIL PROTECTED] wrote: If malware detection systems would not generate a DSN to the originator upon detection in the first place, there would be no need to reduce those transactions as there would be no transactions to reduce. The That is a big if. No shortage of broken software / appliance etc products put out by different vendors Even if they do introduce patches for current versions or release new versions that dont backscatter to spoofing viruses, there's a huge installed base of crap old versions of this stuff. So, fixing that lot is not going to be easy. Sending BATV signed email out and accepting bounces to BATV'd addresses does tend to make sense in a limited set of use cases (IF you send email only from a single server / set of servers, and control the sending client . geeks with pine on *bsd or webmail service providers, or mailing list services that anyway do VERP) Upgrade MTAs around the world? Which MTAs around the world receive bounces bound for your domain, and to your servers? And which MTAs send legitimately send out email with your domain? If you are SURE that all that is covered, try BATV and it will work rather well for you. If you aren't - dont bother about it. -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: SMTP store and forward requires DSN for integrity
I agree with nearly all of your analysis, but want to add a few small points of my own. On Sun, Dec 11, 2005 at 04:53:03AM -0600, Micheal Patterson wrote: Can BATV correct this? Possibly. After reading further and thinking about it: I believe the answer isn't possibly, but almost certainly not. Consider the ~100M zombies (hijacked Windows systems) out there. Mail traffic emitted by any malware resident on them is externally indistinguishable from mail traffic emitted by their former owners (operating under the misconception that it's still their computer). Nos suppose for a moment that we had Email Magic Bullet Technology (EMBT) which enabled us to trace any/all messages back to their origination point. And suppose that 100,000 sites out there (using some form of reliable malware detection) independently using EMBT conclude that they have received copies of the Microsoft Windows virus du jour from [EMAIL PROTECTED] at IP address 1.2.3.4. Thus all 100,000 sites are now in a position, if they wish, to emit a DSN addressed to [EMAIL PROTECTED] stating you have virus blah blah version blah blah etc. My first observation is that emitting these DSNs, even *with* EMBT, is a pointless exercise. Doing so increases, yet again, the volume of useless mail traffic traversing the Internet. It's just more self-promoting spam from AV vendors -- it's not like anyone actually _reads_ this stuff. And even if they did: who's going to read 100,000 messages? My second observation is that the combined volume of these DSNs may constitute a rather effective DDoS on example.com's MXs. My third observation is that such DDoS attacks could easily be redirected against third party mail servers by manipulation of MX records. 4. (I got tired of saying my Nth observation) I'm beginning to conclude that any technology which causes A, in response to traffic from B, to generate traffic to C, is probably not a good idea. 5. Keep in mind that malware resident on a hijacked system is in complete control of the box and thus has access to any cryptographic keys in use as well as any incoming mail being retrieved with POP/IMAP. So even if we presume the existence of a clueful and attentive user (then why is the box in a hijacked state?) there is no guarantee that the DSNs will actually be presented to the user. 6. How is a recipient of a DSN to know that it's authentic? After all, the fact that EMBT enables someone to generate a DSN in response to received virus-contaminated traffic doesn't prevent anyone else from generating a DSN in response to...nothing. Consider a piece of malware which generates such DSNs and its impact on an EMBT. 7. All of the problems cited above become much more interesting if the hijacked box isn't an end-user system, but a mail server. 8. (similar to observation 4) Adding more positive feedback loops to an Internet-wide mail system that already carries far too much junk traffic is a bad move. We need to dampen, not amplify. ---Rsk
SMTP: make it stop
folx, is there *any* way to make this thread die now? it seems that all of the available positions have been staked out and many of the obvious insults and diatriabes have been slung. we are now moving into tangential positions, diatribes and insults. that's usually a sign that the operational content is asymptotically approaching zero. please, let a poor, overworked thread die. thanks, t. -- _ todd underwood chief of operations security renesys - internet intelligence [EMAIL PROTECTED] www.renesys.com
