Re: unwise filtering policy from cox.net

[Leigh Porter]

Robert E. Seastrom wrote:

Barry Shein <[EMAIL PROTECTED]> writes:

  

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.



Once upon a time (1987) there was this experimental facility called MB
(mailbox) records which did exactly that.  Unfortunately, they never
caught on in any real way, and the only historical mark that they seem
to have left is the rather odd way in which we express the RNAME
(mailbox of the responsible party) in an SOA record.

Maybe it's an idea whose time has come again.  How many years would it
take to have a meaningful rollout if we start now?  10?  20?  OK,
nevermind then.  :-P

---Rob

  
Yeah 'cus by then there will be no address space left, all the routers 
would have blown up with too many prefixes, sea levels would have risen 
by 100 M and half the world will be under water. Not to mention the 
fallout from the middle east nuclear exchange, the bird flu epidemic, 
the asteroid hit and that the oil shortage means that China can no 
longer make any cheap plastic tat. If there is no cheap plastic tat, 
then Internet commerce will die because there will be nothing to buy!


--
Leigh

Re: unwise filtering policy from cox.net

[Robert E. Seastrom]

Barry Shein <[EMAIL PROTECTED]> writes:

> 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.

Once upon a time (1987) there was this experimental facility called MB
(mailbox) records which did exactly that.  Unfortunately, they never
caught on in any real way, and the only historical mark that they seem
to have left is the rather odd way in which we express the RNAME
(mailbox of the responsible party) in an SOA record.

Maybe it's an idea whose time has come again.  How many years would it
take to have a meaningful rollout if we start now?  10?  20?  OK,
nevermind then.  :-P

---Rob

Re: unwise filtering policy from cox.net

[Chris Edwards]

On Wed, 21 Nov 2007, Barry Shein wrote:

| Sean's point was that you can't cause, e.g., [EMAIL PROTECTED] alone to
| go to a server other than the same set of servers listed for
| [EMAIL PROTECTED]

Yes of course - but only a fundamental problem where the MX servers are 
hopelessly overloaded.
 
This is different from the situation described in the original post, where 
filtering policy is being applied indiscriminately regardless of recipient 
LHS, which is generally a sign of substandard software or foolish admin.

As others have said, normal practice is to apply different filtering 
policy to certain LHS values (abuse@) and to provision enough MX capacity 
such that the service as a whole is functional (including receiving abuse 
reports).

Re: unwise filtering policy from cox.net

[Suresh Ramasubramanian]

On Nov 22, 2007 3:33 AM, Barry Shein <[EMAIL PROTECTED]> wrote:

> If that ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] or
> [EMAIL PROTECTED] and hope the clients will somehow use that tho for
> BIGCOMPANY there's a tendency to just bang in [EMAIL PROTECTED]

... and the RFC says that, and those people that still do manually
report abuse will email [EMAIL PROTECTED]  or [EMAIL PROTECTED] instead of
hitting report spam and letting their ISP forward it across in a
feedback loop (which will go to an entirely different, machine parsed
address as the ARF spec is designed to let you do).

You can always alias abuse@ internally to a subdomain if you wish -
but that wouldnt be because abuse@ slows down your MXs.  The smtp load
inbound to  an abuse mailbox will be fairly small compared to the
general load of smtp (and spam) coming your users' way for sure.

There's lots of ways to manage an abuse mailbox (such as filter spam
to your abuse mailbox into a bulk folder, review it and then feed it
to scripts that parse the spam and feed the results to your filters).
MAAWG's been working on an abuse desk bcp for quite some time (the
hard / tech part of it, as well as soft abuse stuff like motivating
and training abuse deskers, giving them career paths etc)

--srs
>
> 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 [EMAIL PROTECTED] (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   [EMAIL PROTECTED]   [EMAIL PROTECTED]  Key ID: 64A2FF6A
>  > Fortune:
>  > A plumber is needed, the network drain is clogged
>
> --
> -Barry Shein
>
> The World  | [EMAIL PROTECTED]   | http://www.TheWorld.com
> Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide
> Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
>



-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: unwise filtering policy from cox.net

[Barry Shein]

You're missing the point.

   [EMAIL PROTECTED]

is going to go to whatever MX example.com returns.

Sean's point was that you can't cause, e.g., [EMAIL PROTECTED] alone to
go to a server other than the same set of servers listed for
[EMAIL PROTECTED]

If that ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] or
[EMAIL PROTECTED] and hope the clients will somehow use that tho for
BIGCOMPANY there's a tendency to just bang in [EMAIL PROTECTED]

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 [EMAIL PROTECTED] (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   [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
 > Fortune:
 > A plumber is needed, the network drain is clogged

-- 
-Barry Shein

The World  | [EMAIL PROTECTED]   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: unwise filtering policy from cox.net

[Paul Jakma]

On Wed, 21 Nov 2007, Sean Donelan wrote:



On Tue, 20 Nov 2007, [EMAIL PROTECTED] wrote:

<[EMAIL PROTECTED]>
   (reason: 552 5.2.0 F77u1Y00B2ccxfT000 Message Refused.  A URL in the 
content of your message was found on...uribl.com.  For resolution do not 
contact Cox Communications, contact the block list administrators.)


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  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
A plumber is needed, the network drain is clogged

Re: unwise filtering policy from cox.net

[William Herrin]

On Nov 21, 2007 1:51 AM, Paul Ferguson <[EMAIL PROTECTED]> 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.  This means
>
> Sure, it's an "unfortunate limitation", but I hardly think it's
> an issue to hand-wave about and say "oh, well".
>
> Suggestions?

Standardize on [EMAIL PROTECTED] If an MX exists for
abuse.the-domain-you're-looking-for then send to that instead of to
[EMAIL PROTECTED]

Regards,
Bill Herrin

-- 
William D. Herrin  [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr.Web: 
Falls Church, VA 22042-3004

RE: unwise filtering policy from cox.net

[Frank Bulk]

To be clear, should one be white listing *all* the addresses suggested in
RFC 2142?

Regards,

Frank

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe
Greco
Sent: Wednesday, November 21, 2007 8:30 AM
To: Eliot Lear
Cc: nanog@merit.edu
Subject: Re: unwise filtering policy from cox.net


> Given what Sean wrote goes to the core of how mail is routed, you'd
> pretty much need to overhaul how MX records work to get around this one,
> or perhaps go back to try to resurrect something like a DNS MB record,
> but that presumes that the problem can't easily be solved in other
> ways.  Sean demonstrated one such way (move the high volume stuff to its
> own domain).

Moving "abuse@" to its own domain may work, however, fixing this problem at
the DNS level is probably an error, and probably non-RFC-compliant anyways.

The real problem here is probably one of:

1) Mail server admin "forgot" (FSVO "forgot", which might be "didn't even
   stop to consider," "considered it and decided that it was worthwhile to
   filter spam sent to abuse@, not realizing the implications for abuse
   reporting," "didn't have sufficient knowledge to figure out how to
   exempt abuse@," etc.)

2) Server software doesn't allow exempting a single address; this is a
   common problem with certain software, and the software should be fixed,
   since the RFC's essentially require this to work.  Sadly, it is
   frequently assumed that if you cannot configure your system to do X,
   then it's all right to not do X, regardless of what the RFC's say.

The need to be able to accept unfiltered recipients has certain
implications for mail operations, such as that it could be "bad" to use IP
level filtering to implement a "shared" block for bad senders.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then
I
won't contact you again." - Direct Marketing Ass'n position on e-mail
spam(CNN)
With 24 million small businesses in the US alone, that's way too many
apples.

Re: unwise filtering policy from cox.net

[Rich Kulawiec]

On Wed, Nov 21, 2007 at 06:51:42AM +, Paul Ferguson wrote:
> Sure, it's an "unfortunate limitation", but I hardly think it's
> an issue to hand-wave about and say "oh, well".
> 
> Suggestions?

There are numerous techniques available for addressing this problem.
Which one(s) to use depends on the site's mail architecture, so I'm
not going to try to enumerate them all -- only to give a few examples.

Example 1: exempt abuse@ address from all anti-* processing; just deliver
it.  All the MTA's I've worked with provide features to support this;
it's also sometimes necessary to make that exemption elsewhere (e.g.,
in programs called invoked as milters).  Oh, and don't greylist it either.

Example 2: if using a multi-tier architecture (increasingly a good
idea, as it insulates internal traffic from the beating often inflicted
by external traffic) then re-route abuse@ mail to its own dedicated system
(using a mechanism like the sendmail virtual user table or equivalent).
Make that system something relatively impervious, and choose hardware
that can be replaced quickly at low cost.  (My suggestion: OpenBSD
on a Sparc Ultra 2, and use mutt as the mail client.  Keep a couple
of spares in the basement, they're dirt-cheap.)

---Rsk

Re: unwise filtering policy from cox.net

[Joe Greco]

> Given what Sean wrote goes to the core of how mail is routed, you'd
> pretty much need to overhaul how MX records work to get around this one,
> or perhaps go back to try to resurrect something like a DNS MB record,
> but that presumes that the problem can't easily be solved in other
> ways.  Sean demonstrated one such way (move the high volume stuff to its
> own domain).

Moving "abuse@" to its own domain may work, however, fixing this problem at
the DNS level is probably an error, and probably non-RFC-compliant anyways.

The real problem here is probably one of:

1) Mail server admin "forgot" (FSVO "forgot", which might be "didn't even
   stop to consider," "considered it and decided that it was worthwhile to
   filter spam sent to abuse@, not realizing the implications for abuse 
   reporting," "didn't have sufficient knowledge to figure out how to
   exempt abuse@," etc.)

2) Server software doesn't allow exempting a single address; this is a
   common problem with certain software, and the software should be fixed,
   since the RFC's essentially require this to work.  Sadly, it is 
   frequently assumed that if you cannot configure your system to do X, 
   then it's all right to not do X, regardless of what the RFC's say.

The need to be able to accept unfiltered recipients has certain 
implications for mail operations, such as that it could be "bad" to use IP 
level filtering to implement a "shared" block for bad senders.  

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: unwise filtering policy from cox.net

[Suresh Ramasubramanian]

On Nov 21, 2007 6:21 PM, Eliot Lear <[EMAIL PROTECTED]> wrote:
> Suresh Ramasubramanian wrote:
> > Most mailservers do allow you to exempt specific addresses from filtering.
> >
>
> On the LHS of the @ of a remote address?  I think that was Sean's point.

Er, that bounce was from cox's mta, spamfiltering email to [EMAIL PROTECTED]

-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: unwise filtering policy from cox.net

[Eliot Lear]

Suresh Ramasubramanian wrote:
> Most mailservers do allow you to exempt specific addresses from filtering.
>   

On the LHS of the @ of a remote address?  I think that was Sean's point.

Eliot

Re: unwise filtering policy from cox.net

[Suresh Ramasubramanian]

On Nov 21, 2007 5:46 PM, Eliot Lear <[EMAIL PROTECTED]> wrote:

>
> Given what Sean wrote goes to the core of how mail is routed, you'd
> pretty much need to overhaul how MX records work to get around this one,
> or perhaps go back to try to resurrect something like a DNS MB record,
> but that presumes that the problem can't easily be solved in other
> ways.  Sean demonstrated one such way (move the high volume stuff to its
> own domain).
>

Most mailservers do allow you to exempt specific addresses from filtering.

srs

Re: unwise filtering policy from cox.net

[Eliot Lear]

Hey Paul,

> -- Sean Donelan <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 20 Nov 2007, [EMAIL PROTECTED] wrote:
> >> <[EMAIL PROTECTED]>
> >>(reason: 552 5.2.0 F77u1Y00B2ccxfT000 Message Refused.  A
> URL in
> >> the content of your message was found on...uribl.com.  For
> resolution do
> >>  not contact Cox Communications, contact the block list
> administrators.)
> > 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.  [...]
>
> Sure, it's an "unfortunate limitation", but I hardly think it's
> an issue to hand-wave about and say "oh, well".
>
> Suggestions?

Given what Sean wrote goes to the core of how mail is routed, you'd
pretty much need to overhaul how MX records work to get around this one,
or perhaps go back to try to resurrect something like a DNS MB record,
but that presumes that the problem can't easily be solved in other
ways.  Sean demonstrated one such way (move the high volume stuff to its
own domain).

Eliot