On Tue, 18 May 2004 14:31:21 CDT, Steve Drees said:
if I 0wn your mail gateway I can generate a list of valid accounts over time. On a busy host over a short period of time.
So your auditor wouldn't mind if you kept an unencrypted list of credit card numbers on a DMZ box, because if somebody hacks the box they can gather those over time? :)
On Tue, 18 May 2004 Valdis.Kletnieks@vt.edu wrote:
So your auditor wouldn't mind if you kept an unencrypted list of credit card numbers on a DMZ box, because if somebody hacks the box they can gather those over time? :)
This is hardly the same thing. E-mail addresses are public, credit card numbers aren't. Email addresses can be gotten by brute-force checking fairly easily without even cracking the machine. card numbers can't. What would your auditor think about your secondary MX being used as a DOS amplifier because it sends out thousands of bogus bounces to forged addresses ? ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
On Tue, 18 May 2004 15:48:28 EDT, "Christopher X. Candreva" <chris@westnet.com> said:
What would your auditor think about your secondary MX being used as a DOS amplifier because it sends out thousands of bogus bounces to forged addresses ?
You're missing the main point - that sometimes things are done in ways that are sub-optimal or even pessimal from the technical standpoint, because some other consideration interferes. Yes, it *would* be nice if everybody in the world was able to DTRT on their outward-facing gateway and send back an immediate 550 on a RCPT TO: in order to stop stuff right up front. However, this implies getting buy-in and resources of all the appropriate people. I'm sure *everybody* has had at least one Good Idea either totally shot down or mutated beyond recognition because it wouldn't pass auditors (either internal or external), or because it involved purchasing from Company X because X is the only one with the feature support, but you'll never get that purchase order approved by the "it must be Company Y gear" manager, or because deploying it would involve getting buy-in from somebody in applications development, and they don't understand why the urgency on this new feature you need them to add...
On Tue, 18 May 2004 Valdis.Kletnieks@vt.edu wrote: : Yes, it *would* be nice if everybody in the world was able to DTRT on : their outward-facing gateway and send back an immediate 550 on a RCPT TO: : in order to stop stuff right up front. However, this implies getting : buy-in and resources of all the appropriate people. Blocking outbound mail from such entities is a pretty good way to get buy-in. (Yes, there's a DNSBL in work to enumerate such systems.) -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
On Tue, 18 May 2004 16:13:20 EDT, Todd Vierling said:
On Tue, 18 May 2004 Valdis.Kletnieks@vt.edu wrote:
: Yes, it *would* be nice if everybody in the world was able to DTRT on : their outward-facing gateway and send back an immediate 550 on a RCPT TO: : in order to stop stuff right up front. However, this implies getting : buy-in and resources of all the appropriate people.
Blocking outbound mail from such entities is a pretty good way to get buy-in. (Yes, there's a DNSBL in work to enumerate such systems.)
When it gets built, will it list AOL.COM for not rejecting at the original RCPT TO? Or Hotmail.com? (Consider the following 2 pieces of mail - mail comes in from someplace with a From: @aol.com, our Listserv tries to process the command (which was actually spam, but it's hard to tell that until you try to handle it), and send the response back... notice that AOL didn't 550 my mail, but accepted and bounced it. Similarly for the hotmail.com mail - the spam comes in, and they accept-and-bounce our response rather than 550 it (although to be fair, they usually DO manage to 550 this stuff). Yes, it's generally a good idea - but not one that everybody can carry out all the time. You don't like it, take it up with the AOL and Hotmail guys, not me, OK? :)
On Tue, 18 May 2004 Valdis.Kletnieks@vt.edu wrote:
When it gets built, will it list AOL.COM for not rejecting at the original RCPT TO? Or Hotmail.com? (Consider the following 2 pieces of mail - mail
Don't know about hotmail, but AOL is working on this. You might want to check out that SPAM-L list, if this is something you are interested in. Once AOL starts doing it -- you can bet they will be one of the ones blocking on it. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
On Tue, 18 May 2004 17:11:54 EDT, "Christopher X. Candreva" <chris@westnet.com> said:
Don't know about hotmail, but AOL is working on this. You might want to check out that SPAM-L list, if this is something you are interested in.
Other than knowing that it's a good idea if you can do it, but sometimes not doable with the resources at hand, I don't have any special interest in it...
Once AOL starts doing it -- you can bet they will be one of the ones blocking on it.
That's going to pretty much torpedo the concept of secondary MX's.
On Tue, 18 May 2004 Valdis.Kletnieks@vt.edu wrote: : > Don't know about hotmail, but AOL is working on this. You might want to : > check out that SPAM-L list, if this is something you are interested in. : : Other than knowing that it's a good idea s/a good idea/an emerging requirement/ (and for one definition of the idea, s/a good idea/a soon-to-be RFC "MUST"/) : if you can do it, s/can do it/wish to send mail, or at least DSNs, to most of the 'net soon/ : but sometimes not doable with the resources at hand, s/.*// Those of us under a deluge of virus bounce spew just don't care anymore. If you don't reject at SMTP time, you're now a major part of the problem. (As a straw example, I happen to block, on a personal 12 user domain, almost 20k bounce spew attempts per day. That's simply untenable anymore.) : > Once AOL starts doing it -- you can bet they will be one of the ones : > blocking on it. : : That's going to pretty much torpedo the concept of secondary MX's. And what's the gain of secondary MX's that don't have access to a valid address list? Ever since the advent of globally deployed, permanently connected sending MX's, offsite secondary MX machines have become moot. SMTP mandates that a missed connection is equivalent to a 4xx error, in that the sender is to retry delivery later. That obviates any need for an offsite secondary MX in today's world. Unauditable SMTP transport -- that is, SMTP where neither the sender nor recipient values are verifiable -- is no longer a workable solution. The problems with that model are reaching critical mass, and if you don't think it's a problem now, just trust me; you'll be a believer soon enough. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
On 5/18/2004 4:22 PM, Valdis.Kletnieks@vt.edu wrote:
That's going to pretty much torpedo the concept of secondary MX's.
Folks still run those? No really, most people I know terminated their off-site secondaries a couple of years ago at least. The only secondary you can reasonably use these days has (1) a copy of your user list, and (2) a clone of your spam filters. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On May 18, 5:22pm, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
Once AOL starts doing it -- you can bet they will be one of the ones blocking on it.
That's going to pretty much torpedo the concept of secondary MX's.
Not to suddenly burst back, but ... Second/terti/etc-ary MXers really belong in a bygone age anyway. There was a time when IP was a novelty, and UUCP was king. Then there was a time when UUCP was getting long in the tooth, but politics dictated an IP Internet that was not universally connected. Somewhere in the meantime, leading a life of its own, was something called FidoNet (http://www.fidonet.org) and something else called BITNET (http://www.bitnet.org), but as of today both are for pub brawls only. This is of course an opportune moment to recall that the 10th anniversary of the shutdown of the successor of mcvax.bitnet, namely mcsun.bitnet, was in January of this year. http://www.mcvax.org/mcsun/ The fundamental idea of less preferred MXs was to get the mail delivered through a backdoor, not reachable via IP routing from the originator. Think multihoming for email, keeping in mind that email routing is disjoint from IP routing: a genuine secondary MX would be able to, one way or another, deliver the mail, by means not accessible to the originator. This inaccessibility would be because the more preferred MX was unreachable for one of several reasons (host down, network down, or politics enabled), but, whatever the reason, one wanted to find a way of routing around the problem. For a long time since then, backup MXs have been seen as a kind of value-added courtesy service; they serve no really useful purpose, but look good on a checklist. In practice, of course, in the current Internet it rarely matters on which host an undelivered email is spinning in the spool area. Best, -- Per
On 5/18/2004 6:44 PM, Per Gregers Bilse wrote:
For a long time since then, backup MXs have been seen as a kind of value-added courtesy service; they serve no really useful purpose
well, they're handy for centralizing filters against multiple domains, if you're willing to put your various primaries at the mercy of the filter service, and if the filter knows your valid recipients. what with ldap-smart servers and fancy routing, this isn't even hard anymore. but general "backup" MX is long-time dead. first the spammers killed our outbound flexibility by forcing everybody to close their relays, and then they killed our inbound flexibility by forcing everybody to close their generic backup MX paths. that cracking sound is stress fractures as the network gets more rigid. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On May 18, 7:03pm, "Eric A. Hall" <ehall@ehsco.com> wrote:
For a long time since then, backup MXs have been seen as a kind of value-added courtesy service; they serve no really useful purpose
well, they're handy for centralizing filters against multiple domains, if you're willing to put your various primaries at the mercy of the filter service, and if the filter knows your valid recipients. what with ldap-smart servers and fancy routing, this isn't even hard anymore.
But this only means that the primary, and only, MX should be the filter service MX; in turn, it would deliver sanitized email to its real destination. An amusing twist on this is then that the final recipients could be listed as less preferred MXs -- if the filter service MX is down, one would accept all mail unfiltered, rather than wait until the primary, filter service, MX is back on line. While this would be a legitimate use of less preferred MXs, even if it practically turns the original rationale upside down, I would generally suggest to opt for uncompromising reliablity on a filter service MX, and fall back on DNS changes for disaster recovery, rather than receive tons of junk unfiltered mail whenever there's a glitch on the primary, filter server, MX. But your point is technically correct. Only goes to show how much mileage there is to be had from an otherwise very simple protocol extension.-) Best, -- Per
On Tue, 18 May 2004 Valdis.Kletnieks@vt.edu wrote: : > Blocking outbound mail from such entities is a pretty good way to get : > buy-in. (Yes, there's a DNSBL in work to enumerate such systems.) : : When it gets built, will it list AOL.COM for not rejecting at the original : RCPT TO? AOL happens to be working with the anti-spam community by converting their MXs to do reject-at-SMTP. (See SPAM-L archives. They're quite aware of the problem and are in fact addressing it.) : Or Hotmail.com? Strange; I've received direct SMTP rejections from Hotmail plenty of times recently. Given the size of that entity, I'm sure the DNSBL admin in question would try to work with them (and Hotmail admins have also shown themselves on SPAM-L); but without any movement, yes, it'd be a candidate for listing. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
(was: Re: Barracuda Networks Spam Firewall) Valdis.Kletnieks@vt.edu wrote: | When it gets built, will it list AOL.COM for not rejecting at the original RCPT | TO? Or Hotmail.com? Much as I hate to come to their defence, hotmail rejects unknown users during the dialog, and has done so for as long as I can remember. And AOL is reportedly spending a colossal sum redesigning their mail system to work this way. Goes to underline the importance. The reality is, nowdays, those who can't do things properly themselves should simply host their mail somewhere that can.
on Tue, May 18, 2004 at 11:37:49PM +0100, Chris Edwards wrote:
Much as I hate to come to their defence, hotmail rejects unknown users during the dialog, and has done so for as long as I can remember.
That may be so. But I've got 208 hotmail.com hosts "back"listed for backscatter dreck such as this: --8<----8<----8<-- From MAILER-DAEMON Wed Apr 14 16:17:33 2004 Received: from mc6-s2.hotmail.com (mc6-s2.bay6.hotmail.com [65.54.251.76]) by serrano.hesketh.net (8.12.9p1/8.12.8/NO-UCE-NO-UBE-NO-spam) with ESMTP id i3EKHVAh005383 for <rbghvavo@munged.com>; Wed, 14 Apr 2004 16:17:32 -0400 Received: from mc6-f11.hotmail.com ([65.54.252.147]) by mc6-s2.hotmail.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Apr 2004 13:17:36 -0700 From: postmaster@mail.hotmail.com To: rbghvavo@munged.com Date: Wed, 14 Apr 2004 13:14:29 -0700 MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="9B095B5ADSN=_01C42243E592A444000006B1mc6?f11.hotmail." Message-ID: <EZF98vvwN00000591@mc6-f11.hotmail.com> Subject: Delivery Status Notification (Failure) X-OriginalArrivalTime: 14 Apr 2004 20:17:36.0210 (UTC) FILETIME=[86CCFB20:01C4225D] Content-Length: 7430 Lines: 142 This is a MIME-formatted message. Portions of this message may be unreadable without a MIME-capable mail program. --9B095B5ADSN=_01C42243E592A444000006B1mc6?f11.hotmail. Content-Type: text/plain; charset=unicode-1-1-utf-7 This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. cloud_zero1@hotmail.com --9B095B5ADSN=_01C42243E592A444000006B1mc6?f11.hotmail. Content-Type: message/delivery-status Reporting-MTA: dns;mc6-f11.hotmail.com Received-From-MTA: dns;accsports.com Arrival-Date: Wed, 14 Apr 2004 13:14:19 -0700 Final-Recipient: rfc822;cloud_zero1@hotmail.com Action: failed Status: 5.2.3 Diagnostic-Code: smtp;552 5.2.3 This message is larger than the current system limit or the recipient's mailbox is full. Create a shorter message body or remove attachments and try sending it again. --8<----8<----8<-- Granted, it's a DSN for an over-quota user, not a nonexistent user, but the rejection happens after accept, and the DNS goes to the forged sender. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com Buy "Cascading Style Sheets: Separating Content from Presentation, 2/e" today! http://www.amazon.com/exec/obidos/ASIN/159059231X/heskecominc-20/ref=nosim/
On Tue, 18 May 2004, Steven Champeon wrote:
Granted, it's a DSN for an over-quota user, not a nonexistent user, but the rejection happens after accept, and the DNS goes to the forged sender.
OK Steve let me know when you have the sendmail ruleset to check quota on a remote host before accepting RCPT To: :-) ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
on Tue, May 18, 2004 at 07:17:58PM -0400, Christopher X. Candreva wrote:
On Tue, 18 May 2004, Steven Champeon wrote:
Granted, it's a DSN for an over-quota user, not a nonexistent user, but the rejection happens after accept, and the DNS goes to the forged sender.
OK Steve let me know when you have the sendmail ruleset to check quota on a remote host before accepting RCPT To: :-)
Not the point. Point is that mail sent to a hotmail.com address from a forged sender was accepted, was not delivered, and the DSN sent to the forged sender. It's not really my business why a hotmail.com MX accepted mail it couldn't deliver. I could care less /why/. It's up to hotmail to fix their systems - I don't care how they perform that background check on quota. It's my business that over the past sixty days, we've had to reject over 23K of these, and had rejected some 130K in three weeks during March, at the peak of the joe job. At one point, backscatter accounted for 70% of my inbound email traffic on one host. Almost made the usual spam and virus look like background noise. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com Buy "Cascading Style Sheets: Separating Content from Presentation, 2/e" today! http://www.amazon.com/exec/obidos/ASIN/159059231X/heskecominc-20/ref=nosim/
Quoting Steven Champeon (schampeo@hesketh.com):
It's not really my business why a hotmail.com MX accepted mail it couldn't deliver. I could care less /why/. It's up to hotmail to fix their systems - I don't care how they perform that background check on quota.
Exactly.
It's my business that over the past sixty days, we've had to reject over 23K of these, and had rejected some 130K in three weeks during March, at the peak of the joe job. At one point, backscatter accounted for 70% of my inbound email traffic on one host. Almost made the usual spam and virus look like background noise.
36K backscatter rejects from hotmail yesterday but only 2K from AOL. AOL has really got their act together compared to hotmail, verizon, comcast, and the like. May 18 00:00:05 mx1 postfix/smtpd[11977]: 6F8F315DC0: reject: RCPT from mc1-s21.bay6.hotmail.com[65.54.163.161]: 550 <xjlljuzisexmj@tuffmail.co.uk>: Recipient address rejected: User unknown; Probably forged by Alan Ralsky; from=<> to=<xjlljuzisexmj@tuffmail.co.uk> proto=ESMTP helo=<mc1-s21.hotmail.com> It was 80K daily from hotmail till I dropped the MX records for 4 of the domains being forged. If anyone would like to test their capability to reject 1+ million a day I can point the MX records to your servers. :-) John Capo Tuffmail.com
On Tue, 18 May 2004 Valdis.Kletnieks@vt.edu wrote:
You're missing the main point - that sometimes things are done in ways that are sub-optimal or even pessimal from the technical standpoint, because some other consideration interferes. Yes, it *would* be nice if everybody in the world
Oh, I know that point very well. It's why we're in the mess we are in, because no one could budget to set things up properly. It's the same arguement we heard as to why people couldn't close their open relays. To which we eventually responded "OK, if that's what you have to do. Let us know when you have fixed it and we'll accept mail from you again. You'll have to use a different server though, 'cause it's blocked now". It's not that I missed the point. I don't care if YOU can't afford it. That's your problem. I'm not going to let it affect MY network. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
You're missing the main point - that sometimes things are done in ways that are sub-optimal or even pessimal from the technical standpoint, because some other consideration interferes. Yes, it *would* be nice if everybody in the world
But if you really need a reason to convince someone who won't get their head out of their . . . the sand -- You can probably cut in half the number of viruses you have to scan if you reject invalid addresses up front, meaning you can buy a smaller/ fewer virus scanner(s). Which means the companies making them have absolutely no incentive to add this feature. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
On Tue, 18 May 2004 16:56:30 EDT, "Christopher X. Candreva" <chris@westnet.com> said:
But if you really need a reason to convince someone who won't get their head out of their . . . the sand -- You can probably cut in half the number of viruses you have to scan if you reject invalid addresses up front, meaning you can buy a smaller/ fewer virus scanner(s).
Which means the companies making them have absolutely no incentive to add this feature.
Right. Mirapoints are that way too (at least in our configuration). And yes, we'll probably have to buy a 5th Mirapoint and/or upgrade our current 4 sooner because of it - but the incremental cost for that is *still* lower than the cost of replacing them with another vendor's gear.... Now how do you explain to the CFO that in order to get around a $50K upgrade to the current gear, you want to spend $200K to bring in another vendor? :)
participants (8)
-
Chris Edwards -
Christopher X. Candreva -
Eric A. Hall -
John Capo -
Per Gregers Bilse -
Steven Champeon -
Todd Vierling -
Valdis.Kletnieks＠vt.edu