Randy Martin ( email@example.com )
Sun, 23 Mar 1997 22:03:30 -0600
At 08:16 PM 3/23/97 -0500, you wrote:
>At 06:57 PM 3/23/97 -0600, Daryl Banttari wrote:
>>I've been following this post.office spammer thread with some interest.
>>Here's an idea:
>>Set up a machine as a mail forwarder (only), and point MX to it. Use
>>only a hosts file for name resolution (disable DNS) so that the only
>>machine the forwarder can look up by name is the "real" mail server.
>>Make sure the hosts file includes an entry for the domain itself that
>>points to the real mail server. Any SMTP for your system goes through
>>through the forwarder to the real mail host, and any mail hitting that
>>"inbound" mail server for other mail servers dies as undeliverable.
>>Then block tcp:25 in to your "real" mail server. It's kludgy but it may
>>work for some of you with a spare machine and a few hours of time.
>>It does nothing to actually fix the core problem, i.e. buggy software
>>and poor support, but I'm offering this suggestion for those of you
>>pushed against the wall by this.
>So lets see, we build a product that adheres to the IETF standard for MTA
>relaying, and you call it "buggy" as a result? I don't think that's fair.
>I understand your pain WRT spam, but the problem is *not* a bug, it's
>adherence to the spec that defines how our product interoperates across the
>Internet. And *any* mailserver that conforms to the IETF spec is
>susceptible to being used as a spam relay.
>What we're working on is a workaround to the problem, one that doesn't
>corrupt the spec we must adhere to.
Oh, bull shit, Lee! Spec, schmeck! That's the biggest bunch of marketing
mumbo jumbo I've read in a long time! Of course it's a bug! Are you trying
to tell us that the people who designed the spec left this loophole in
there on purpose? Or that they just didn't think of it? If that's the case,
then it's a bug in the spec! So, be a standup software company and say that
you don't think the spec is correct in this case and just fix the damn
Getting more frustrated with each passing post,
Randy Martin Voice: (512) 335-2368
Partner eMail: firstname.lastname@example.org
Austin Internet Access URL: http://www.austintx.net