nanog mailing list archives
Re: unwise filtering policy from cox.net
From: Barry Shein <bzs () world std com>
Date: Wed, 21 Nov 2007 17:03:04 -0500
You're missing the point. xx () example com is going to go to whatever MX example.com returns. Sean's point was that you can't cause, e.g., eg () example com alone to go to a server other than the same set of servers listed for AnythingElse () example com. If that (eg () example com) overloads those servers, even if they're valiantly trying to pass the connection off to another machine, then you have to use some other method like eg () special example com or eg () other-domain com and hope the clients will somehow use that tho for BIGCOMPANY there's a tendency to just bang in abuse () BIGCOMPANY COM. It can be a problem in joe jobs, as one e.g. If you think I'm wrong (or Sean's wrong) even for a milisecond then trust me, this is going right over your head. Think again or email me privately and I'll try to be more clear. P.S. It's an interesting thought. The only approach to a solution I could imagine is that the whole address would have to be passed in the MX query. On November 21, 2007 at 21:06 paul () clubi ie (Paul Jakma) wrote:
An unfortunate limitation of the SMTP protocol is it initially only looks at the right-hand side of an address when connecting to a server to send e-mail, and not the left-hand side.full) or the normal server administrators may make changes which affects all addresses passing through that server (i.e. block by IP address).I guess you're saying there's something architectural in email that makes it impossible/difficult (limitation) to apply different policy to the LHS. That's not correct though. The receiving MTA is quite free to apply differing policies to different LHSes. And at least one MTA allows you special-case measures applied to tables of addresses, such as whether DNSbl lookups should be applied. SMTP is distributed, so you do of course have to take care to keep distributed policy consistent. But, again, that has nowt to do with LHS/RHS of email addresses. regards, -- Paul Jakma paul () clubi ie paul () jakma org Key ID: 64A2FF6A Fortune: A plumber is needed, the network drain is clogged
-- -Barry Shein The World | bzs () TheWorld com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
Current thread:
- Re: unwise filtering policy from cox.net, (continued)
- Re: unwise filtering policy from cox.net Joe Greco (Nov 20)
- [admin] Re: unwise filtering policy from cox.net Alex Pilosov (Nov 20)
- Re: [admin] Re: unwise filtering policy from cox.net Martin Hannigan (Nov 20)
- Re: unwise filtering policy from cox.net Martin Hannigan (Nov 20)
- RE: unwise filtering policy from cox.net Raymond L. Corbin (Nov 20)
- Re: unwise filtering policy from cox.net Valdis . Kletnieks (Nov 20)
- Re: unwise filtering policy from cox.net Chris Owen (Nov 20)
- Re: unwise filtering policy from cox.net chuck goolsbee (Nov 20)
- Re: unwise filtering policy from cox.net Valdis . Kletnieks (Nov 20)
- Re: unwise filtering policy from cox.net Sean Donelan (Nov 20)
- Re: unwise filtering policy from cox.net Paul Jakma (Nov 21)
- Re: unwise filtering policy from cox.net Barry Shein (Nov 21)
- Re: unwise filtering policy from cox.net Suresh Ramasubramanian (Nov 21)
- BOTNET reference involving oscilloscope Howard C. Berkowitz (Nov 23)
- Re: BOTNET reference involving oscilloscope Leigh Porter (Nov 23)
- Re: BOTNET reference involving oscilloscope Adrian Chadd (Nov 23)
- Re: unwise filtering policy from cox.net Paul Jakma (Nov 21)
- Re: unwise filtering policy from cox.net Chris Edwards (Nov 21)
- Re: unwise filtering policy from cox.net Robert E. Seastrom (Nov 21)
- Re: unwise filtering policy from cox.net Leigh Porter (Nov 21)
- Re: unwise filtering policy from cox.net Suresh Ramasubramanian (Nov 22)
- Re: unwise filtering policy from cox.net Adrian Chadd (Nov 22)
- Re: unwise filtering policy from cox.net Suresh Ramasubramanian (Nov 22)