-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Sean Donelan <sean@donelan.com> wrote:
On Tue, 20 Nov 2007, goemon@anime.net wrote:
<abuse@cox.net> (reason: 552 5.2.0 F77u1Y00B2ccxfT0000000 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. This means abuse@example.com first passes through the same server as all of the rest of *@example.com e-mail. A single high-volume or special address can easily overwhelm the normal email infrastructure (i.e. mailbox full) or the normal server administrators may make changes which affects all addresses passing through that server (i.e. block by IP address).
Sure, it's an "unfortunate limitation", but I hardly think it's an issue to hand-wave about and say "oh, well". Suggestions? - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHQ9V5q1pz9mNUZTMRAvCjAJ9VGB/7LicKsAXUwSwbmRVntfXm8gCgjEYT y9YWpm8OhqCDI5nPDBy6kZY= =OqQL -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Hey Paul,
-- Sean Donelan <sean@donelan.com> wrote:
On Tue, 20 Nov 2007, goemon@anime.net wrote:
<abuse@cox.net> (reason: 552 5.2.0 F77u1Y00B2ccxfT0000000 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
On Nov 21, 2007 5:46 PM, Eliot Lear <lear@cisco.com> 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
On Nov 21, 2007 6:21 PM, Eliot Lear <lear@cisco.com> 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 abuse@cox.net -- Suresh Ramasubramanian (ops.lists@gmail.com)
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.
To be clear, should one be white listing *all* the addresses suggested in RFC 2142? Regards, Frank -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] 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.
On Wed, Nov 21, 2007 at 06:51:42AM +0000, 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
On Nov 21, 2007 1:51 AM, Paul Ferguson <fergdawg@netzero.net> 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 abuse@abuse.domain.whatever? If an MX exists for abuse.the-domain-you're-looking-for then send to that instead of to abuse@the-main-domain? Regards, Bill Herrin -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
participants (7)
-
Eliot Lear -
Frank Bulk -
Joe Greco -
Paul Ferguson -
Rich Kulawiec -
Suresh Ramasubramanian -
William Herrin