Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Apr 2002 23:44:48 -0800
From:      "Philip J. Koenig" <pjklist@ekahuna.com>
To:        Questions@FreeBSD.ORG
Cc:        Benjamin Krueger <benjamin@macguire.net>
Subject:   Re: hub.freebsd.org spam policy
Message-ID:  <20020405074448067.AAA353@empty1.ekahuna.com@pc02.ekahuna.com>
In-Reply-To: <20020404223902.G2470@rain.macguire.net>
References:  <20020405052942787.AAA368@empty1.ekahuna.com@pc02.ekahuna.com>; from pjklist@ekahuna.com on Thu, Apr 04, 2002 at 09:29:42PM -0800

next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Apr 2002, at 22:39, Benjamin Krueger boldly uttered: 

> * Philip J. Koenig (pjklist@ekahuna.com) [020404 21:30]:
> > On 5 Apr 2002, at 13:45, Greg 'groggy' Lehey boldly uttered: 
> > 
> > > On Thursday,  4 April 2002 at 16:46:08 -0800, Philip J. Koenig wrote:
> > > > On 4 Apr 2002, at 15:26, Benjamin Krueger boldly uttered:
> > > >
> > > >> * irado (irado@subdimension.com) [020404 15:11]:
> > > 
> > > There are many possible reasons for that.  In general, we don't have
> > > too much sympathy for people who have configuration problems and then
> > > blame us for rejecting their mail.
> > 
> > I do not have a "configuration problem".  If you read what I wrote, 
> > you would have seen that I have been using variations of the same 
> > email client for around 7 years and have NEVER had this problem 
> > before freebsd.org decided to implement this filtering.
> 
> You are aware of the difference between a Mail Client (MUA) and a Mail Server
> (MTA), Right?


I sure am.  Your point?  The filter that caused me to not be able to 
send email to anywhere at freebsd.org had nothing to do with any MTA 
on my end.

I do not have a "configuration problem" as far as anywhere on the 
internet is concerned except freebsd.org.  If you'd like to assert 
otherwise with any credible corroboration, please go ahead.


> > There are a plethora of methods in use today for blocking spam.  The 
> > problem in my view are the methods which PURPORT to be "spam 
> > blockers", but which are actually "wing and a prayer" things based on 
> > faulty and over-generalized assumptions.  Inherent in most of these 
> > are the arrogance of site administrators who aren't much concerned 
> > about all the collateral damage they cause.
> 
> What's with this "collateral damage" you keep bandying about? This is a free
> resource. Nobody is damaged because they cannot get a free resource being
> given away.


Apparently you don't spend much time discussing the subject.  
"Collateral damage" pertains to the damage which occurs to 
legitimate, non-spam messages by "anti-spam" measures.  Damage is 
defined in this case generally as delivery failure of one kind or 
another which is solely due to the "anti-spam" measures.

 
> > I'll tell you exactly what the problem was.  The filters at 
> > hub.freebsd.org are designed to block *anything* that has a message-
> > ID that ends in "localhost".  EVEN TO POSTMASTER.. which is a very 
> > rude practice.
> 
> Perhaps you consider it rude. The rest of us will consider it compliant.


Not if you read and comply with RFC's like 2821, which defines the 
SMTP standard.

And I may as well assert that "the rest of us" have green skin, with 
as much credibility.  Don't bother.  Your datapoints are lacking.

 
> > I have been using various versions of this email client (Pegasus 
> > Mail) since around 1995, and as far as I know, my messages have been 
> > formatted that way for the last seven years and I have never *once* 
> > gotten a complaint or a bounceback due to that reason... until now.
> > 
> > Now the guy who answers postmaster@freebsd.org says the reasoning 
> > behind this is that various spammers supposedly use "@localhost" in 
> > their Message-ID headers.  But THE PROBLEM with this is that lots of 
> > us who have *nothing to do with spam* also do this.. and have for 
> > years.
> 
> If your mail server does that, it is broken. Period. End of Story.


The mail server does NOT do that, it is the client that does. (and 
which did in this case)


> There is no, I repeat, No reason for a mail server anywhere on the Internet to
> report itself as the domain "localhost". You do not own @localhost. You Cannot
> own @locahost. @locahost is not a valid TLD now, nor has it ever been, and
> likely it never will be.


What a brilliant revelation.  Too bad it has nothing to do with "the 
problem".  Too bad no one else in the world seems to care.

 
> > I cannot think of any other large email list that is so naive to 
> > think that they can operate without any sort of subscriber 
> > verification and still have a handle on spamming and abuse.  There 
> > are many "anti-spam" practices which foist undue burdens on users - 
> > asking for list subscription confirmation is NOT one of them as far 
> > as I'm concerned.  How can a person consider it to be a 'burden' to 
> > receive and reply to an almost instantaneous return email, when this 
> > is precisely the mechanism which they will have to use to make use of 
> > list traffic to get a question answered anyway?  In any event this 
> > last point is moot because the freebsd lists now apparently ask for 
> > confirmation.  I tested this myself today.
> 
> Often, new users will email the list with one or two questions, and have no
> interest or need to follow it after that. Signing up for a list, confirming,
> asking your questions, getting your answers, and then unsubscribing, is
> something of a hassle. Presumably the list postmasters considered this, and
> opted for user needs.


Virtually all high-profile mailing lists today ask for verification 
of subscriptions because to not do so entails a plethora of problems 
- from spamming, flooding, pranksters who subscribe people against 
their will, etc.  I don't have to "presume" this, it is just a simple 
fact.  The only case where I think "single opt-in" is a reasonable 
option for a list maintainer are one-way lists where users cannot 
post messages. (and only when there is a very high degree of 
confidence that users want to be on the list - such as companies or 
other entities where you already have a relationship with them)

The interesting thing is that now the freebsd lists require 
authentication.  Greg claims it's been this way "for years", 
yet A) I see no evidence of this when I subscribed to 5 freebsd lists 
at one time back in 11/2000 (I save everything including the 
majordomo response messages) and B) it makes no sense if people were 
truly arguing passionately to provide "open access".  So which is it -
are the lists "open access" or not?  If they aren't, how could the 
last sentence of this assertion of yours make any sense:

> Often, new users will email the list with one or two questions,
> and have no interest or need to follow it after that. Signing up
> for a list, confirming, asking your questions, getting your
> answers, and then unsubscribing, is something of a hassle.
> Presumably the list postmasters considered this, and opted for user
> needs. 



> Frankly, the list didn't have much spam when we allowed non-verified
> subscribers to post, so I fail to see how this screamed "spammers come here".


And when did this policy change?  Greg claims it's been that way "for 
years".

All I remember is that not more than 6-9 months ago, the list was 
awash in junk messages to the point where I seem to recall receiving 
some digests which contained nothing but a single spam message.
 
Now for all of you who are making vain attempts to paint my position 
about list verification as some "whacko opinion", please read this:

http://www.mail-abuse.org/manage.html

I trust you are aware of who MAPS/mail-abuse.org and Paul Vixie are.


Quoting:

"Permission of new subscribers must be fully verified before mailings 
commence."



> > And about this "bad DNS", I assume you are assuming something must 
> > match forward/reverse?  What are you testing DNS on, the last-hop 
> > host?  What happens if it has several A records or CNAME records?  
> > 
> > I just finished setting up a client today with a well-regarded 
> > web/domain hosting company (matter of fact, they are 100% FreeBSD) 
> > and the hostname they provide for that client to use is actually a 
> > CNAME which doesn't match the PTR record.  Are we going to designate 
> > them "spammers" now? (caveat: in this case we're talking about a POP3 
> > host, but this is also pretty common with MX hosts)
> 
> Common DNS Operational and Configuration Errors 
> RFC 1912, Section 2.1, Paragraph 2:
> 
>   Make sure your PTR and A records match.  For every IP address, there
>   should be a matching PTR record in the in-addr.arpa domain.  If a
>   host is multi-homed, (more than one IP address) make sure that all IP
>   addresses have a corresponding PTR record (not just the first one).
>   Failure to have matching PTR and A records can cause loss of Internet
>   services similar to not being registered in the DNS at all. Also,
>   PTR records must point back to a valid A record, not a alias defined
>   by a CNAME.  


Nothing in what you are quoting above says that it is a "requirement" 
for the forward/reverse to match, just that it "can cause loss of 
internet connectivity".  That of course depends on the policy of the 
destination host.  And while it's a perfectly fine ideal, in the real 
world lots of hosts (particularly in Asia, some parts of Europe and 
the developing world) don't have PTR records.  Do we just 
automatically throw away their messages, regardless whether they are 
"spam" or not?  Sounds a little overboard to me.

You see the problem with all of these arguments is that they always 
seek to justify their existing decisions (don't accept messages that 
look like this or that), and many times those decisions are based on 
questionable logic.  In particular, logic which results in innocent 
users having their traffic dropped on the ground as "spam" because 
they don't meet a plethora of unreasonable conditions.


> > > And your solution?  I see a lot of bitching, but no suggestions about
> > > how to improve it.  I'm not surprising you're not getting your
> > > viewpoint across.
> > 
> > I haven't gotten to the point of discussing specifics yet because I'm 
> > still trying to get past all the "bitching" about the simple fact 
> > I've pointed these things out.
> 
> Please, we're all waiting for your wisdom.


I can see that.  It would help if certain individuals didn't start 
out making snide comments (ie about my "bitching" and so forth).. 
perhaps it would set the stage for real dialogue instead of the 
namecalling-fest we now find ourselves wading through.


> > In short - and I will continue this later if there is an interest - 
> > "anti-spam" measures must TARGET SPAM, not "something that sorta 
> > looks like spam".
> 
> So we need filters that target spam, instead of filters that target spam?


No, "anti-spam" filters should not be arbitrary.  There are ways of 
identifying spam that are much more accurate than just looking for 
strings like "localhost" appearing in the message-ID, or assuming 
that every host without a PTR record is automatically a "spam-
generator".  I began to point out some of these earlier.


> Here in the real world, spam does not always announce itself as being so. Very
> few spams say "Here I am, I'm a Spam!". As such, the next best method is to
> target things that look like spam, and behave like spam.


No, it's not the next best thing - unless you are utterly unaware of 
the entire universe of anti-spam remedies. (could be, I've seen no 
evidence so far to refute that)

 
> > I'm sure you are aware of DNS email blacklists.  The problem with 
> > many of these is that their only criteria is whether a host is an 
> > "open relay" or not.  The problem is that a host could sit there as 
> > an open relay for 5 years and never send a single spam message.  So 
> > the likelihood of "collateral damage" is high.  Likewise site-wide 
> > filters that match on things like "make money fast" strings.  While 
> > you might get a low percentage of false positives, you will 
> > undoubtedly eventually block legitimate traffic.
> 
> False Positives are part of life. Alarms are not fail-proof, the justice
> system is not fail-proof, your car's safety systems are not fail-proof, etc.
> Should we throw out all of these safety mechanisms (spam filters are a safety
> mechanism) simply because they can make mistakes?


Never said they should be thrown out.  (Why do these arguments always 
take the same path: criticize a particular methodology, the defenders 
rush to try to accuse you of not wanting anything.  If the previous 
patterns hold true, the next accusation is going to be that I must 
personally be a spammer if I'm critical about anyone's blocking 
methodology.)


> I'm very sorry that your mail host is broken. If you insist on brokeness,
> thats your perogative, but don't parade about shouting that folks who reject
> your mail are causing collateral damage on the internet. Like the great Gord
> says, "Just because you say it doesn't make it so".


Neither does your repeated attempt to claim I have a "broken mail 
host" have any likelihood of ever becoming true because of your 
continued repetition of it.

The only difference between my previous inability to either post to 
the freebsd lists or send email to postmaster@freebsd.org had to do 
with an undocumented setting that I changed in my MUA.  No change was 
made to the MTA that relayed the message.  (and for the umpteenth 
time, no one in the world cared about that MUA setting over the last 
7 years -- including lots of 'anti-spammer' types and 'anti-spammer' 
organizations -- until a few weeks ago at freebsd.org)  



--
Philip J. Koenig                                       pjklist@ekahuna.com
Electric Kahuna Systems -- Computers & Communications for the New Millenium


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020405074448067.AAA353>