Sender ID got turned down by both the IETF and Time Warner/AOL as a way to
solve the spam problem. The issue has apparently nothing to do with the
technical merits of MSFT's solution, but rather, with concerns of these
parties and the open source community that MSFT would somehow use this to
get some sort of leverage, based on past MSFT's business practices.

Here's a take on the subject from TF:

http://gruia.blogware.com/blog/_archives/2004/9/17/142790.html

Question: is there something being developed on this front by any Linux
vendor or third-pary open source developer?  I imagine the answer is "yes",
but have there been any alternative proposals been made to the IETF?

In article <2Ai3d.4519$bL1.86900@news20.bellglobal.com>, John Doe wrote:
> Sender ID got turned down by both the IETF and Time Warner/AOL as a way to
> solve the spam problem. The issue has apparently nothing to do with the
> technical merits of MSFT's solution, but rather, with concerns of these
> parties and the open source community that MSFT would somehow use this to
> get some sort of leverage, based on past MSFT's business practices.

Of course.  M~FT needs to replace the public SMTP email system
with something that hinders its competition and generates a revenue stream.
Adding a patented feature does exactly that.


> Here's a take on the subject from TF:
> 
> http://gruia.blogware.com/blog/_archives/2004/9/17/142790.html
> 
> Question: is there something being developed on this front by any Linux
> vendor or third-pary open source developer?  I imagine the answer is "yes",

Sender Policy Framework  http://spf.pobox.com/



Cameron

On 19 Sep 2004 17:26:02 GMT, Cameron L. Spitzer wrote:

> In article <2Ai3d.4519$bL1.86900@news20.bellglobal.com>, John
> Doe wrote:
>
>> Sender ID got turned down by both the IETF and Time Warner/AOL
>> as a way to solve the spam problem. The issue has apparently
>> nothing to do with the technical merits of MSFT's solution,
>> but rather, with concerns of these parties and the open source
>> community that MSFT would somehow use this to get some sort of
>> leverage, based on past MSFT's business practices.
>
> Of course.  M~FT needs to replace the public SMTP email system
> with something that hinders its competition and generates a
> revenue stream.  Adding a patented feature does exactly that.
>
>
>> Here's a take on the subject from TF:
>>
>> http://gruia.blogware.com/blog/_archives/2004/9/17/142790.html
>>
>> Question: is there something being developed on this front
>> by any Linux vendor or third-pary open source developer?  I
>> imagine the answer is "yes",
>
> Sender Policy Framework http://spf.pobox.com/
>

Looks promising. From that site:

<quote>

In this example, AOL.com is the sending domain, and
pobox.com is the receiver.

AOL publishes an SPF record, specifying which computers on
the Internet can send mail as user@aol.com

1. When a real AOL user sends mail, pobox.com receives the
message from an AOL server. 

2. Pobox checks AOL's SPF record, to make sure the server is allo
wed to send mail from AOL.
3. The server is listed, so Pobox gives the message a pass.

(Expensive content-based spam checks can be bypassed, saving reso
urces on the receiver side.)

-------------

1. When a spammer forges mail from AOL, Pobox receives the
 messages from an outside server.

2. Pobox checks AOL's SPF record.

3. The server is not listed, so Pobox gives the message a
fail.

(Expensive content-based spam checks can be bypassed, saving reso
urces on the receiver side.)

.....

If you do get spam that passed an SPF check, then you know you
should hold the sending domain responsible for the message.


</quote>

http://spf.pobox.com/howworks.html


AC



-- 
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb

Alan Connor wrote:

> In this example, AOL.com is the sending domain, and
> pobox.com is the receiver.
> 
> AOL publishes an SPF record, specifying which computers on
> the Internet can send mail as user@aol.com
> 
> 1. When a real AOL user sends mail, pobox.com receives the
> message from an AOL server.
> 
> 2. Pobox checks AOL's SPF record, to make sure the server is allo
> wed to send mail from AOL.
> 3. The server is listed, so Pobox gives the message a pass.
> 
> (Expensive content-based spam checks can be bypassed, saving reso
> urces on the receiver side.)

So the spammer sends mail from a trojaned AOL user with a fake aol.com
address, and the spam gets through.

On Sun, 19 Sep 2004 23:39:55 +0100, Jonathan Bryce wrote:

> So the spammer sends mail from a trojaned AOL user with a fake aol.com
> address, and the spam gets through.

Thats a problem SPF isn't trying to solve. All the SPF does is stop
address spoofing.

-- 
Try `stty 0' -- it works much better.

On Sun, 19 Sep 2004 23:39:55 +0100, Jonathan Bryce
<jonathan@localhost.localdomain> wrote:

> Alan Connor wrote:
>
>> In this example, AOL.com is the sending domain, and pobox.com
>> is the receiver.
>>
>> AOL publishes an SPF record, specifying which computers on the
>> Internet can send mail as user@aol.com
>>
>> 1. When a real AOL user sends mail, pobox.com receives the
>> message from an AOL server.
>>
>> 2. Pobox checks AOL's SPF record, to make sure the server is
>> allo wed to send mail from AOL.  3. The server is listed, so
>> Pobox gives the message a pass.
>>
>> (Expensive content-based spam checks can be bypassed, saving
>> reso urces on the receiver side.)
>
> So the spammer sends mail from a trojaned AOL user with a fake
> aol.com address, and the spam gets through.

Yeh. That could happen. Or they could sign up for AOL (how many
months free?) using a hundred different names, spam from each
until they got shut down, then dump it and move to the next.

Same for any major ISP: Their bureaucracies are dumb as bricks
and slow as molasses in January, CYA being the name of the game,
and the people in charge aren't the ones that understand the
networking protocols and their real world applications.

But SPF still looks like it would help a lot. Could just be a
file the MTA accessed that was updated every hour from an SPF
server. That would be often enough, I'm guessing.

AC

-- 
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb

Geoffrey King wrote:

> On Sun, 19 Sep 2004 23:39:55 +0100, Jonathan Bryce wrote:
> 
>> So the spammer sends mail from a trojaned AOL user with a fake
>> aol.com address, and the spam gets through.
> 
> Thats a problem SPF isn't trying to solve. All the SPF does is stop
> address spoofing.
> 

It's still a big improvement.

-- 
Donovan Hill
Canadian, Linux User, All around nice guy!

Jonathan Bryce <jonathan@localhost.localdomain> wrote:
> Alan Connor wrote:
> > In this example, AOL.com is the sending domain, and
> > pobox.com is the receiver.
> > AOL publishes an SPF record, specifying which computers on
> > the Internet can send mail as user@aol.com
> > 1. When a real AOL user sends mail, pobox.com receives the
> > message from an AOL server.
> > 2. Pobox checks AOL's SPF record, to make sure the server is allo
> > wed to send mail from AOL.
> > 3. The server is listed, so Pobox gives the message a pass.
> > (Expensive content-based spam checks can be bypassed, saving reso
> > urces on the receiver side.)
> So the spammer sends mail from a trojaned AOL user with a fake aol.com
> address, and the spam gets through.

....but only through AOL's mailserver farm, so they can detect and either 
rate-limit or shut down consumer accounts that are sending ~way~ too 
much mail for a consumer. 

(next, you say: "Okay, so they send only a small number of messages each 
through a large number of trojanned AOL users, and the spam gets 
through") 

....but still only through AOL's mailserver farm, so they can detect 
large numbers of customers all sending substantively similar messages, 
and shut down ALL of them. 

-- 
Huey

In news.admin.net-abuse.email - article <AuSdnRyov8Ahl9PcRVn-
iA@eclipse.net.uk>, on Sun, 19 Sep 2004 23:39:55 +0100, Jonathan 
Bryce says...
> Alan Connor wrote:
> 
> > In this example, AOL.com is the sending domain, and
> > pobox.com is the receiver.
> > 
> > AOL publishes an SPF record, specifying which computers on
> > the Internet can send mail as user@aol.com
> > 
> > 1. When a real AOL user sends mail, pobox.com receives the
> > message from an AOL server.
> > 
> > 2. Pobox checks AOL's SPF record, to make sure the server is allo
> > wed to send mail from AOL.
> > 3. The server is listed, so Pobox gives the message a pass.
> > 
> > (Expensive content-based spam checks can be bypassed, saving reso
> > urces on the receiver side.)
> 
> So the spammer sends mail from a trojaned AOL user with a fake aol.com
> address, and the spam gets through.

Read this before discarding SPF for it's intended purpose.  
http://spf.pobox.com/rationale.txt

It's not a spam solution, it's a forgery prevention tool and it's a 
no-lose situation for both sender and receiver.  Quite simple for the 
sender to implement and depending on your SMTP server it could be 
simple for the receiver to implement.

The targeted advantage is not for the receiver but the sender.  I'm 
really surprised that banks and phishing targets like paypal haven't 
jumped on immediately.  A simple line of text in their DNS will help 
thwart financial phishers and reduce their customer service costs.

Top left hand corner of the home page  http://spf.pobox.com

SPF: Sender Policy Framework 
The Anti-Forgery solution
That's making the world a
Safer place for email.

http://spf.pobox.com/faq.html#churn mentions spam but only to the 
effect that it will disrupt some spammer methods, admitting to an 
"arms race" but you now have a choice of whether you will allow a 
spammer to victimize you by forging your domain, resulting in floods 
of bounces back to you and diminishing the value of your domain name.  
You are now "master of your domain" not implying the Seinfeld 
connotation.

Adelphia already has a strict designation of what IP addresses are 
authorised to send email with a from address containing 
@adelphia.net.

    v=spf1 mx ip4:68.168.78.0/24 -all

If it has a From: containing @adelphia.net, it must come from 
68.168.78.0/24, no exceptions.  Anything else and they expect that 
you will treat it as spam.  I applaud them for instituting SPF strict 
and early regardless of any of their other flaws.

Several years back Juno.com was almost driven to extinction because 
they were the top forged domain.  @juno.com had become a "spam 
signature".

There are some side effects that will impact spam, some things twice 
removed.  I think as a result, some trojans will evolve to attempt to 
hijack the local Outlook to send spam, this will result in consumer 
networks like Adelphia cleaning up their trojaned clients more 
quickly.

Spammers will begin to publish their own SPF but will have to rotate 
through domains rapidly, increasing work and cost.

They'll be forced to manage fewer, larger centralized DNS servers 
with domains that can be revoked, if we can maintain the current 
trend of registrars canceling spam domains.  We've got to educate 
them on how to remove registered name servers.

On Sun, 19 Sep 2004 21:56:51 -0400, Murray Watson wrote:

> We've got to educate them on how to remove registered name servers.

What does that mean?

In news.admin.net-abuse.email - article 
<pan.2004.09.20.02.15.38.117238@yahoo.com>, on Sun, 19 Sep 2004 
21:15:42 -0500, Dave Uhring says...
> On Sun, 19 Sep 2004 21:56:51 -0400, Murray Watson wrote:
> 
> > We've got to educate them on how to remove registered name servers.
> 
> What does that mean?

It's in this thread Message-ID: <16d694b9.0409131408.216e49c4@posting.google.com>

http://groups.google.com/groups?&threadm=16d694b9.0409131408.216e49c4%40posting.google.com

On Sun, 19 Sep 2004 23:03:30 -0400, Murray Watson wrote:

> In news.admin.net-abuse.email - article 
> <pan.2004.09.20.02.15.38.117238@yahoo.com>, on Sun, 19 Sep 2004 
> 21:15:42 -0500, Dave Uhring says...
>> On Sun, 19 Sep 2004 21:56:51 -0400, Murray Watson wrote:
>> 
>> > We've got to educate them on how to remove registered name servers.
>> 
>> What does that mean?
> 
> It's in this thread Message-ID: <16d694b9.0409131408.216e49c4@posting.google.com>
> 
> http://groups.google.com/groups?&threadm=16d694b9.0409131408.216e49c4%40posting.google.com

That does not answer the question about what a "registered name server"
is.  When I register a domain the technical information I provide is the
domain name and the IP addresses or hostnames of the two name servers
which are authoritative for that domain.

What is a "registered name server" which you want removed?

"Dave Uhring <daveuhring@yahoo.com>" wrote in news.admin.net-abuse.email:

[sNip]
> That does not answer the question about what a "registered name server"
> is.  When I register a domain the technical information I provide is the
> domain name and the IP addresses or hostnames of the two name servers
> which are authoritative for that domain.
> 
> What is a "registered name server" which you want removed?

    	A "registered name server" is, essentially, a host record as 
maintained by Network Solutions (I'm not sure if other Registrars do/can 
participate in this, but I've heard that Network Solutions manages this 
aspect of DNS and they provide management of host records as a free 
service) and used by the root servers for DNS resolution more reliably.

    	The "host" can be looked up in Network Solutions' WHOIS server, for 
example one of my host records is as follows:

    	    	telnet whois.networksolutions.com 43
    	    	host netware.inter-corporate.com
[sNip]
    	    	Hostname: NETWARE.INTER-CORPORATE.COM
    	    	Address: 24.87.56.253
    	    	System: ? running ?
[sNip]
    	    	<Connection terminated by remote.>

    	Regardless of how I configure my DNS zone to return a different IP 
address for "netware.inter-corporate.com," the root servers will override 
this by providing the information specified in the host record.  This also 
seems to speed up DNS resolutiona little bit, by the way, because the root 
servers don't have to take addition steps to look up external NS records.

    	Since it would be impossible for DNS to function if we relied entirely 
on DNS servers by name, the "host" record is needed to set up a "registered 
name server."

    	One of my criteria for picking a Registrar is that they understand 
this concept and can support it.  So far only Network Solutions has 
satisfied me in this regard, which is one of the many reasons I use them as 
my Registrar.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

In article <Xns9569E13EBF5F2rr8xca@24.64.223.211>,
Randolf Richardson  <rr@8x.ca> wrote:

>    	A "registered name server" is, essentially, a host record as 
>maintained by Network Solutions (I'm not sure if other Registrars do/can 
>participate in this, but I've heard that Network Solutions manages this 
>aspect of DNS and they provide management of host records as a free 
>service) and used by the root servers for DNS resolution more reliably.


>    	Regardless of how I configure my DNS zone to return a different IP 
>address for "netware.inter-corporate.com," the root servers will override 
>this by providing the information specified in the host record.  This also 
>seems to speed up DNS resolutiona little bit, by the way, because the root 
>servers don't have to take addition steps to look up external NS records.
>
>    	Since it would be impossible for DNS to function if we relied entirely 
>on DNS servers by name, the "host" record is needed to set up a "registered 
>name server."
>
>    	One of my criteria for picking a Registrar is that they understand 
>this concept and can support it.  So far only Network Solutions has 
>satisfied me in this regard, which is one of the many reasons I use them as 
>my Registrar.

Your concept of how the domain name system works differs substantially
from mine.  If my notions are right, then the best I can say for your
notions is that I'm glad someone was willing to accept your money and
give you the crazy snake oil you needed.  I'm a little disappoitned
that the only snake oil vendor you found is that enthusiastic sender
of unsolicited bulk email and world leading marketing machine to the
clue-resistant and government agencies.


Vernon Schryver    vjs@rhyolite.com

On Mon, 20 Sep 2004 05:02:55 +0000, Randolf Richardson wrote:

> 
>     	A "registered name server" is, essentially, a host record as 
> maintained by Network Solutions (I'm not sure if other Registrars do/can 
> participate in this, but I've heard that Network Solutions manages this 
> aspect of DNS and they provide management of host records as a free 
> service) and used by the root servers for DNS resolution more reliably.

More reliably?  How about a "whois microsoft.com"?

Verisign's security and reliability are laughable.


Thank you for the explanation.

On Mon, 20 Sep 2004 05:02:55 +0000, Randolf Richardson wrote:

>     	Regardless of how I configure my DNS zone to return a different IP 
> address for "netware.inter-corporate.com," the root servers will override 
> this by providing the information specified in the host record.  This also 
> seems to speed up DNS resolutiona little bit, by the way, because the root 
> servers don't have to take addition steps to look up external NS records.

I also think that someone is putting something over on you:

Non-authoritative answer:
Name:   netware.inter-corporate.com
Address: 24.87.56.253

Authoritative answers can be found from:
inter-corporate.com     nameserver = netware.inter-corporate.com.
inter-corporate.com     nameserver = oc48.inter-corporate.com.
inter-corporate.com     nameserver = fast01.inter-corporate.com.
oc48.inter-corporate.com        internet address = 64.251.89.8
fast01.inter-corporate.com      internet address = 64.251.89.88

Suppose you turn off those three DNS servers and then attempt to resolve
some host whose zone records are maintained there.

On Sun, 19 Sep 2004 23:12:25 -0600, Vernon Schryver wrote:

> Your concept of how the domain name system works differs substantially
> from mine.  If my notions are right, then the best I can say for your
> notions is that I'm glad someone was willing to accept your money and
> give you the crazy snake oil you needed.  I'm a little disappoitned
> that the only snake oil vendor you found is that enthusiastic sender
> of unsolicited bulk email and world leading marketing machine to the
> clue-resistant and government agencies.

Is it time to buy some of Verisign's stock?

"vjs@calcite.rhyolite.com (Vernon Schryver)" wrote in
news.admin.net-abuse.email: 

[sNip]
> Your concept of how the domain name system works differs substantially
> from mine.  If my notions are right, then the best I can say for your
[sNip]

    	What's your understanding of the purpose of these "host" records?

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

"Dave Uhring <daveuhring@yahoo.com>" wrote in news.admin.net-abuse.email:

> On Mon, 20 Sep 2004 05:02:55 +0000, Randolf Richardson wrote:
> 
>>          A "registered name server" is, essentially, a host record as 
>> maintained by Network Solutions (I'm not sure if other Registrars do/can 
>> participate in this, but I've heard that Network Solutions manages this 
>> aspect of DNS and they provide management of host records as a free 
>> service) and used by the root servers for DNS resolution more reliably.
> 
> More reliably?  How about a "whois microsoft.com"?

    	Not found on Network Solutions' WHOIS server.  They use OpenSRS.Net.

> Verisign's security and reliability are laughable.

    	Although there are been many attempts by third parties over the years 
to transfer internet domain names, my Registrar has always required 
confirmation from me before proceeding.

    	Of course, whenever I asked my clients about such transfer requests, 
it was always a suprise to them, so I changed our company policy to reject 
or ignore all such requests unless the client contacts us first.

    	So far, I'm pretty happy with the results.

> Thank you for the explanation.

    	You're welcome, but please also consider Vernon's explanation as he's 
well-respected and probably knows better than me (according to the 
anecdotes I've read around here about him).

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

"Dave Uhring <daveuhring@yahoo.com>" wrote in news.admin.net-abuse.email:

> On Mon, 20 Sep 2004 05:02:55 +0000, Randolf Richardson wrote:
> 
>> Regardless of how I configure my DNS zone to return a different IP 
>> address for "netware.inter-corporate.com," the root servers will
>> override this by providing the information specified in the host
>> record.  This also seems to speed up DNS resolutiona little bit, by the
>> way, because the root servers don't have to take addition steps to look
>> up external NS records. 
> 
> I also think that someone is putting something over on you:
> 
> Non-authoritative answer:
> Name:   netware.inter-corporate.com
> Address: 24.87.56.253
> 
> Authoritative answers can be found from:
> inter-corporate.com     nameserver = netware.inter-corporate.com.
> inter-corporate.com     nameserver = oc48.inter-corporate.com.
> inter-corporate.com     nameserver = fast01.inter-corporate.com.
> oc48.inter-corporate.com        internet address = 64.251.89.8
> fast01.inter-corporate.com      internet address = 64.251.89.88
> 
> Suppose you turn off those three DNS servers and then attempt to resolve
> some host whose zone records are maintained there.

    	I'm aware of how this is all configured.  Of course, if I turn off my 
DNS servers and wait for caches to expire, the only items that will resolve 
are the registered name servers.

    	I know it works this way too because I've run across a few registered 
host names that resolved in the past, yet the IPs they resolved to weren't 
running any DNS servers (queries against them simply timed out).  The only 
reason I discovered these was when I was troubleshooting eMail delivery 
problems for clients.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

In comp.os.linux.security Alan Connor <zzzzzz@xxx.yyy> wrote:
> But SPF still looks like it would help a lot. Could just be a
> file the MTA accessed that was updated every hour from an SPF
> server. That would be often enough, I'm guessing.

You do a real-time lookup via the DNS. Take a look at some of the
many articles describing how to use/implement SPF. One I liked
was published a few months ago by Linux Journal (part 1 of 2 is at
http://www.linuxjournal.com/article.php?sid=7327).

SPF's big advantage is that it provides for authentication of domains
without blocking domains that have not subscribed to its approach. It
does have disadvantages (header rewriting required for email forwarding,
no authentication of users, to name but two), but because it's as easy
as pie to sign up for what is effectively an anonymous dial-up account
from any ISP, I don't believe it's the right place to solve that problem.

Chris

"chris-usenet@roaima.co.uk" wrote in news.admin.net-abuse.email:

[sNip]
> SPF's big advantage is that it provides for authentication of domains
> without blocking domains that have not subscribed to its approach.
[sNip]

    	That all depends on how it gets implemented.  Someone could just as 
easily configure their SMTP servers to reject all IDNs (Internet Domain 
Names) that don't have SPF records.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

On Mon, 20 Sep 2004 09:33:10 +0100, chris-usenet@roaima.co.uk
<chris-usenet@roaima.co.uk> wrote:


> In comp.os.linux.security Alan Connor <zzzzzz@xxx.yyy> wrote:
>
>> But SPF still looks like it would help a lot. Could just be a
>> file the MTA accessed that was updated every hour from an SPF
>> server. That would be often enough, I'm guessing.
>
> You do a real-time lookup via the DNS. Take a look at some of
> the many articles describing how to use/implement SPF. One I
> liked was published a few months ago by Linux Journal (part 1
> of 2 is at http://www.linuxjournal.com/article.php?sid=7327).
>

Thanks. I'll read that.

> SPF's big advantage is that it provides for authentication of
> domains without blocking domains that have not subscribed to
> its approach. It does have disadvantages (header rewriting
> required for email forwarding, no authentication of users, to
> name but two), but because it's as easy as pie to sign up for
> what is effectively an anonymous dial-up account from any ISP,
> I don't believe it's the right place to solve that problem.
>
> Chris

SPF doesn't have to solve every problem that plagues email.
I think we agree on that. But it looks to me like it would
help with a lot of them.

I'd favor eliminating the Bcc header too: If someone wants
to keep the names of other subscribers to a mailing list
from each subscriber, then they'd have to send out a seperate
mail to each one. This would be *very* easy to implement.

AC

-- 
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb

"Alan Connor <zzzzzz@xxx.yyy>" wrote in news.admin.net-abuse.email:

[sNip]
> I'd favor eliminating the Bcc header too: If someone wants
> to keep the names of other subscribers to a mailing list
> from each subscriber, then they'd have to send out a seperate
> mail to each one. This would be *very* easy to implement.

    	It's pretty obvious that you don't really know how SMTP works...

    	An eMail client will typically display "BCC:" information to the user 
composing the message (so they can choose hidden recipients), but the 
"BCC:" field will be omitted when sending multiple "RCPT TO:" commands for 
a single SMTP Envelope (this is one of the ways that eMail is quite 
different from Postal Mail; the Post Office can't duplicate letters when 
multiple recipients are listed on a single envelope).

    	Also, mailing list servers don't typically use "BCC:" headers for the 
same reason.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

In article <pan.2004.09.20.03.26.57.116887@yahoo.com>,
 Dave Uhring <daveuhring@yahoo.com> wrote:

> On Sun, 19 Sep 2004 23:03:30 -0400, Murray Watson wrote:
> 
> > In news.admin.net-abuse.email - article 
> > <pan.2004.09.20.02.15.38.117238@yahoo.com>, on Sun, 19 Sep 2004 
> > 21:15:42 -0500, Dave Uhring says...
> >> On Sun, 19 Sep 2004 21:56:51 -0400, Murray Watson wrote:
> >> 
> >> > We've got to educate them on how to remove registered name servers.
> >> 
> >> What does that mean?
> > 
> > It's in this thread Message-ID: 
> > <16d694b9.0409131408.216e49c4@posting.google.com>
> > 
> > http://groups.google.com/groups?&threadm=16d694b9.0409131408.216e49c4%40post
> > ing.google.com
> 
> That does not answer the question about what a "registered name server"
> is.  When I register a domain the technical information I provide is the
> domain name and the IP addresses or hostnames of the two name servers
> which are authoritative for that domain.

Correction: IP addresses AND hostnames. This is relevant to your 
question...

> What is a "registered name server" which you want removed?

There is a free-standing A record carried by each TLD root for each 
authoritative nameserver used by domains in the TLD. It used to be that 
you had to register those nameservers as a separate process from domain 
registration, but now it seems that the registry records get created 
every time a new authoritative server is referenced by a domain record. 

This provides a sort of backdoor nameservice that is effectively 
bulletproof. The name is resolvable even if it is in a domain without 
nameservice, because the TLD roots have that glue record.

-- 
Now where did I hide that website...

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-17573-1095678847-0003
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Beavis writes:

> I'd favor eliminating the Bcc header too:

Beavis: the Bcc: header is already "eliminated", either by the MUA right off 
the bat, or by its smarthost.

>                                           If someone wants
> to keep the names of other subscribers to a mailing list
> from each subscriber, then they'd have to send out a seperate
> mail to each one. This would be *very* easy to implement.

It's only easy because you don't have to implement it yourself.


--=_mimegpg-commodore.email-scan.com-17573-1095678847-0003
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBTrt/x9p3GYHlUOIRAiLRAJ9qGrsaTeXPMBQAqu41kcuJmriCXwCeMQg7
3YZlsGk0bwm0fPzWqGSon2k=
=YQb+
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-17573-1095678847-0003--

In article <Xns9569E13EBF5F2rr8xca@24.64.223.211>,
 Randolf Richardson <rr@8x.ca> wrote:

>  This also 
> seems to speed up DNS resolutiona little bit, by the way, because the root 
> servers don't have to take addition steps to look up external NS records.

It would not be the roots doing the extra query. 

>     	Since it would be impossible for DNS to function if we relied entirely 
> on DNS servers by name, the "host" record is needed to set up a "registered 
> name server."

Not quite impossible without some of those records, but the chain of 
dependencies would be more complex and riskier. Without the glue A 
records you could not have nameservers for a domain in-zone for that 
domain, and you would have to make sure that the nameservers used for 
each domain are resolvable. Eventually the chain of domains would end 
with some domain with a glue A record in the TLD root. 

>     	One of my criteria for picking a Registrar is that they understand 
> this concept and can support it.  So far only Network Solutions has 
> satisfied me in this regard, which is one of the many reasons I use them as 
> my Registrar.

That's a misconception. 

Note that the incompetent spamming fraudsters at NSI are not my 
registrars, yet:

; <<>> DiG 9.2.3 <<>> +norecurse @a.gtld-servers.net ns.scconsult.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9425
;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ns.scconsult.com.              IN      A

;; ANSWER SECTION:
ns.scconsult.com.       172800  IN      A       66.73.230.190


I believe the only thing NSI does that is different in this regard is 
that they may still require customers to go through a distinct host 
registration process which some other registrars do not. That is not 
entirely a bad thing, but it is not really essential and in the past 
they have not always done a great job of it.

-- 
Now where did I hide that website...

In article <pan.2004.09.20.05.44.32.396471@yahoo.com>,
 Dave Uhring <daveuhring@yahoo.com> wrote:

> On Mon, 20 Sep 2004 05:02:55 +0000, Randolf Richardson wrote:
> 
> >     	Regardless of how I configure my DNS zone to return a different IP 
> > address for "netware.inter-corporate.com," the root servers will override 
> > this by providing the information specified in the host record.  This also 
> > seems to speed up DNS resolutiona little bit, by the way, because the root 
> > servers don't have to take addition steps to look up external NS records.
> 
> I also think that someone is putting something over on you:
> 
> Non-authoritative answer:
> Name:   netware.inter-corporate.com
> Address: 24.87.56.253
> 
> Authoritative answers can be found from:
> inter-corporate.com     nameserver = netware.inter-corporate.com.
> inter-corporate.com     nameserver = oc48.inter-corporate.com.
> inter-corporate.com     nameserver = fast01.inter-corporate.com.
> oc48.inter-corporate.com        internet address = 64.251.89.8
> fast01.inter-corporate.com      internet address = 64.251.89.88
> 
> Suppose you turn off those three DNS servers and then attempt to resolve
> some host whose zone records are maintained there.

No need to do that, all I need to do is ask a gTLD root and make sure it 
doesn't try to help me too much:

; <<>> DiG 9.2.3 <<>> +norecurse @a.gtld-servers.net 
netware.inter-corporate.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17684
;; flags: qr; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;netware.inter-corporate.com.   IN      A

;; ANSWER SECTION:
netware.inter-corporate.com. 172800 IN  A       24.87.56.253

;; AUTHORITY SECTION:
inter-corporate.com.    172800  IN      NS      
fast01.inter-corporate.com.
inter-corporate.com.    172800  IN      NS      
netware.inter-corporate.com.
inter-corporate.com.    172800  IN      NS      oc48.inter-corporate.com.

;; ADDITIONAL SECTION:
fast01.inter-corporate.com. 172800 IN   A       64.251.89.88
netware.inter-corporate.com. 172800 IN  A       24.87.56.253
oc48.inter-corporate.com. 172800 IN     A       64.251.89.8

;; Query time: 163 msec
;; SERVER: 192.5.6.30#53(a.gtld-servers.net)
;; WHEN: Mon Sep 20 07:41:08 2004
;; MSG SIZE  rcvd: 163

So, without anyone talking to those 3 nameservers, I have address 
records for each of them. If I was really only trying to resolve one of 
them, I would never get to the point of querying them directly.

-- 
Now where did I hide that website...

In article <Xns9569EB1EF1DF1rr8xca@24.64.223.211>,
Randolf Richardson  <rr@8x.ca> wrote:

>> Your concept of how the domain name system works differs substantially
>> from mine.  If my notions are right, then the best I can say for your

>    	What's your understanding of the purpose of these "host" records?

This is not the forum for an extended tutorial on the domain name
system.  I doubt there is a good place for an audience consisting of
people who cannot be bothered to read the relevant RFCs or a tutorial
such as Cricket's.  (See http://www.google.com/search?q=cricket+dns )

   - Are you talking about NSI's host handles, DNS HOST RRs, DNS NS RRs,
      Internic nameserver whois records, or something else?  There are
      host RRs, but they are not required by anything and all but
      unrelated to NSI's host "handles" or Internic nameserver whois
      records.  There are NS RRs, but they are both required by the
      DNS and something else entirely.

   - If whatever you think you mean by "host records" were required
      or even particularly useful for the operation of the DNS, how
      would the DNS continue to function with, according to you, only
      NSI supporting them?

   - I assume you mean host handles.  Network Solutions support for
      host handles has ebbed and flowed over the years.  As I recall,
      they are a legacy from SRI.

   - Look for the notion of DNS glue records.

   - Think what you might do if you were in charge of NSI's registry
      and needed to keep track the DNS servers authoritative for domains
      you are registering, and wanted to consolidate the IP address
      and registrar of each such host.  Whatever you did could not
      be part of the domain name system itself, because there is
      no room for your "host records" there.

   - To get an idea of how the DNS really works, except for obscure
      optimizations such as the use of anycasting, set up a private
      domain name system of your own including roots and gTLDs.  If
      you have a 3 or 4 spare computers that can run BIND behind a
      firewall, this is easy and instructive.  See also "split DNS"
      "private DNS," and related concepts.


Vernon Schryver    vjs@rhyolite.com

Randolf Richardson <rr@8x.ca> wrote:
> "Alan Connor <zzzzzz@xxx.yyy>" wrote in news.admin.net-abuse.email:
>> I'd favor eliminating the Bcc header too: If someone wants
>> to keep the names of other subscribers to a mailing list
>> from each subscriber, then they'd have to send out a seperate
>> mail to each one. This would be *very* easy to implement.
> 
>        It's pretty obvious that you don't really know how SMTP works...
> 
>        An eMail client will typically display "BCC:" information to the user 
> composing the message (so they can choose hidden recipients), but the 
> "BCC:" field will be omitted when sending multiple "RCPT TO:" commands for 
> a single SMTP Envelope ...

You and Sam are perhaps misinterpreting Alan.  I suspect he knows that
the Bcc field is dropped by MTAs, but is proposing that its use be
banned, because spammers abuse it.

-- 
John Wingate                        Mathematics is the art which teaches
johnww@worldpath.net                one how not to make calculations.
                                                         --Oscar Chisini

MW> [SPF is] not a spam solution, [...]

And indeed this is well known in certain circles, including the MARID 
working group.

<URL:news://news.gmane.org./20040914064058.GB15185@nic.fr>
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-spf-is-harmful.html>

Nonetheless, it continues to be advertised as such:

"SPF reduces inbound spam."
-- <URL:http://spf.pobox.com./execsumm.html>

"If the message fails SPF tests, it's a forgery.
That's how you can tell it's probably a spammer."
-- <URL:http://spf.pobox.com./faq.html>
(That first sentence is a lie, of course.)

"Eventually, as SMTP improves its immunity to spam,
we hope spammers will get discouraged."
-- <URL:http://spf.pobox.com./faq.html>

"'Why should SPF succeed when similar proposals have failed
in the past?'  The spam problem was never as bad in the past
as it is now."
-- <URL:http://spf.pobox.com./faq.html>

"Saving the world from spam is an expensive duty."
-- <URL:http://spf.pobox.com./donations.html>

"John Wingate <johnww@worldpath.net>" wrote in news.admin.net-abuse.email:

> Randolf Richardson <rr@8x.ca> wrote:
[sNip]
>> It's pretty obvious that you don't really know how SMTP works...
>> 
>> An eMail client will typically display "BCC:" information to the user 
>> composing the message (so they can choose hidden recipients), but the 
>> "BCC:" field will be omitted when sending multiple "RCPT TO:" commands
>> for a single SMTP Envelope ...
> 
> You and Sam are perhaps misinterpreting Alan.  I suspect he knows that
> the Bcc field is dropped by MTAs, but is proposing that its use be
> banned, because spammers abuse it.

    	It's a pipe dream on his part.

    	Things were designed this way so that users could send a message to a 
number of people they know (e.g., a group of their customers) without 
letting each of them know who the others are.  It's really a matter of 
allowing people to protect others' privacy, and to take this option away 
from end users would set a very bad precedent.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

Dave Uhring <daveuhring@yahoo.com> wrote in message news:<pan.2004.09.20.03.26.57.116887@yahoo.com>...
> On Sun, 19 Sep 2004 23:03:30 -0400, Murray Watson wrote:
> 
> > In news.admin.net-abuse.email - article 
> > <pan.2004.09.20.02.15.38.117238@yahoo.com>, on Sun, 19 Sep 2004 
> > 21:15:42 -0500, Dave Uhring says...
> >> On Sun, 19 Sep 2004 21:56:51 -0400, Murray Watson wrote:
> >> 
> >> > We've got to educate them on how to remove registered name servers.
> >> 
> >> What does that mean?
> > 
> > It's in this thread Message-ID: <16d694b9.0409131408.216e49c4@posting.google.com>
> > 
> > http://groups.google.com/groups?&threadm=16d694b9.0409131408.216e49c4%40posting.google.com
> 
> That does not answer the question about what a "registered name server"
> is.  When I register a domain the technical information I provide is the
> domain name and the IP addresses or hostnames of the two name servers
> which are authoritative for that domain.
> 
> What is a "registered name server" which you want removed?

"registered host" is more accurate, some call it a "registered
server".  I'm not sure of any other uses for registered hosts other
than nameservers.  I'm sure there are but it is predominantly used for
nameservers.

When your dns resolver looks-up hotmail.com to find the IP address for
hotmail's "www" server or it's mail server, it first looks to
root-servers.net to see who's responsibile for .com which is
gtld-servers.net.
gtld-servers.net is then queried to find the NS records (nameservers)
for hotmail.com.  ns1.hotmail.com among others is returned, now the
resolver asks GTLD servers for the respective IP addresses for the
nameserver names returned by the prior query, how else will it know
the IP address of ns1.hotmail.com.

For the GTLD servers to function as a dns server of sorts for
hotmail.com to provide IP addresses of hotmail.com's dns servers,
hotmail.com must have registered specific hostnames and their
corresponding IP address as well as what the designated nameserver
names are for the domain hotmail.com.  Hence the name "registered
host".

This setup works well for a hosting company like rackspace.com that
provides DNS for thousands of domains.  If they change the IPs of
nameservers provided for their customers use, all they need to do is
change the IP address of the registered host.  They won't have to do
anything on a per domain basis.  junkdtectr.com will be pointing to
ns1.rackspace.com as it's nameserver.

That's my take on it anyway.  Would someone please correct me if I've
got something wrong.

In article <Xns956A631A192CArr8xca@24.64.223.211>,
Randolf Richardson  <rr@8x.ca> wrote:

>    	It's a pipe dream on his part.
>
>    	Things were designed this way so that users could send a message to a 
>number of people they know (e.g., a group of their customers) without 
>letting each of them know who the others are.  It's really a matter of 
>allowing people to protect others' privacy, and to take this option away 
>from end users would set a very bad precedent.

True.

It's also technically unenforceable, unless you make a massive set of
changes to the email infrastructure.  To enforce it, you'd have to
pass along the entire set of addressees as part of every SMTP
transaction, as well as listing them in the envelope, so that the
receiving MTA could check for the presence of "blind" (unlisted)
addressees.

-- 
Dave Platt <dplatt@radagast.org>                                   AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
  I do _not_ wish to receive unsolicited commercial email, and I will
     boycott any company which has the gall to send me such ads!

Randolf Richardson wrote:

>     	It's a pipe dream on his part.
> 
>     	Things were designed this way so that users could send a message to a 
> number of people they know (e.g., a group of their customers) without 
> letting each of them know who the others are.

Yes, that's the reason (probably). But if I understood AC correctly,
he wants the BCC mechanism to go away. Instead, he wants that every
mail is directly adressed and that Envelope To: and the To:/CC: in
the body ("header") of a mail are the same. He wants that *BLIND* part
of Bcc to go away.

>  It's really a matter of 
> allowing people to protect others' privacy, and to take this option away 
> from end users would set a very bad precedent.

You misunderstood him. Instead of writing a mail which has

To: me@adress.is.invalid

He wants every mail to have

To: him@adress.is.not.invalid

Now, to protect the privacy, this might mean, that every mail has
just one recipient, which would increase the number of mails that
have to be sent by a spammer. Right now, with Bcc:, a spammer only
has to deliver 1 (one) mail and have the MTA deliver it to every
"Bcc adress". With no bcc, the spammer would need to deliver as
many mails as there are recipients.

> 


Alexander Skwar
-- 
<dark> Knghtbrd: We have lots of whatevers.
<Knghtbrd> dark - In Debian?  Hell yeah we do!
������������������������������������������������������������������������

On Mon, 20 Sep 2004 09:40:38 -0700, Murray Watson wrote:

> Dave Uhring <daveuhring@yahoo.com> wrote in message news:<pan.2004.09.20.03.26.57.116887@yahoo.com>...
>> On Sun, 19 Sep 2004 23:03:30 -0400, Murray Watson wrote:
>> 
>> > In news.admin.net-abuse.email - article 
>> > <pan.2004.09.20.02.15.38.117238@yahoo.com>, on Sun, 19 Sep 2004 
>> > 21:15:42 -0500, Dave Uhring says...
>> >> On Sun, 19 Sep 2004 21:56:51 -0400, Murray Watson wrote:
>> >> 
>> >> > We've got to educate them on how to remove registered name servers.

>> What is a "registered name server" which you want removed?

> For the GTLD servers to function as a dns server of sorts for
> hotmail.com to provide IP addresses of hotmail.com's dns servers,
> hotmail.com must have registered specific hostnames and their
> corresponding IP address as well as what the designated nameserver
> names are for the domain hotmail.com.  Hence the name "registered
> host".

Now if Microsfot's hotmail.com domain were revoked would its domain name
still be associated with ns[1|2|3|4].hotmail.com and further associated
with IP addresses assigned to those nameservers at the GTLD servers?

If not then just what does this mean "We've got to educate them on how
to remove registered name servers."?

Alexander Skwar wrote:

> Randolf Richardson wrote:
> 
> 
>>    	It's a pipe dream on his part.
>>
>>    	Things were designed this way so that users could send a message to a 
>>number of people they know (e.g., a group of their customers) without 
>>letting each of them know who the others are.
> 
> 
> Yes, that's the reason (probably). But if I understood AC correctly,
> he wants the BCC mechanism to go away. Instead, he wants that every
> mail is directly adressed and that Envelope To: and the To:/CC: in
> the body ("header") of a mail are the same. He wants that *BLIND* part
> of Bcc to go away.
> 

The concept of Bcc: predates electronic mail of any sort. The 
concept of Bcc: comes from manual, paper office procedure, as does 
Cc:. The meaning of Cc: is "courtesy copy", Bcc: is "blind 
courtesy copy". Both are intended to cause those listed in the Cc: 
or Bcc: to recieve copies of the message. In the case of Cc:, the 
recipient is "public", that is all recipients know that they got 
it because it is listed on the physical paper. In the case of 
Bcc:, the Bcc: recipients are not listed; only the sender knows 
that they received a copy.

The concept of Cc:, Bcc: was carried forward by the designers of 
email systems as a direct remapping of [then] current office 
procedure and protocol. SMTP does not distinguis between To:, Cc:, 
and Bcc:. The To:, Cc:, Bcc: headers are, just that: headers 
meaningful to mail clients [what you use on your machine to read 
and write email] and as an audit trail of what happened to it 
along its life. All recipients are the object of the "rcpt to" 
command. That the Bcc: mechanism is abused by spammers is 
unfortunate. The concepts are still relevant.

There are some effective techniques to help manage mail where you 
are Bcc'd on wanted mail. I believe both OE and Mozilla mail 
clients will support these techniques.
= Whitelist email lists you subscrib to and want to receive.
= Filter all mail you receive into a spambox where your email 
address is not in the To: or Cc: headers. Very, Very effective.

JMHO.
   "Rex"

-- 
The email address in the From: line of this message is a
spamtrap. Mail sent to this address may get the sender's
mailserver listed in one or more DNSBLs. -- Rex Karz

Bill Cole <bill@scconsult.com> wrote in message news:<bill-0B3B04.07041620092004@toaster.scconsult.com>...
> There is a free-standing A record carried by each TLD root for each 
> authoritative nameserver used by domains in the TLD. It used to be that 
> you had to register those nameservers as a separate process from domain 
> registration, but now it seems that the registry records get created 
> every time a new authoritative server is referenced by a domain record. 

The registrars still have to explicitly register the nameservers. 
They probably hide it from the users, though.  The only thing that has
changed in regard to .com/.net glue records is that Verisign now
allows the same IP address to be listed many times with different host
names.  Previously, a strict 1-1 relationship was preserved.

On 2004-09-20, Rex Karz wrote:
> The concept of Bcc: predates electronic mail of any sort. The 
> concept of Bcc: comes from manual, paper office procedure, as does 
> Cc:. The meaning of Cc: is "courtesy copy",

    In fact, "cc:" means "copies", "c:" is "copy".

    The word "courtesy" was introduced by people who didn't know the
    meaning, and retrofitted an acronym.

-- 
    Chris F.A. Johnson                  http://cfaj.freeshell.org/shell
    ===================================================================
    My code (if any) in this post is copyright 2004, Chris F.A. Johnson
    and may be copied under the terms of the GNU General Public License

"Alan Connor" <zzzzzz@xxx.yyy> wrote in message
news:Obx3d.437$g42.228@newsread3.news.pas.earthlink.net...
> On Mon, 20 Sep 2004 09:33:10 +0100, chris-usenet@roaima.co.uk
> <chris-usenet@roaima.co.uk> wrote:
>
>
> I'd favor eliminating the Bcc header too: If someone wants
> to keep the names of other subscribers to a mailing list
> from each subscriber, then they'd have to send out a seperate
> mail to each one. This would be *very* easy to implement.
>

I might be getting hold of the wrong end of the stick, but the "BCC header"
has nothing to do with email delivery - delivery addresses are part of the
SMTP envelope, and nothing to do with any of the headers (which are part of
the content). From a protocol point of view there is no correlation between
the recipient requested by SMTP and the information about who the message is
to within the message headers.

Blane.

On Mon, 20 Sep 2004 09:14:22 GMT, Alan Connor <zzzzzz@xxx.yyy> wrote:

>I'd favor eliminating the Bcc header too: If someone wants
>to keep the names of other subscribers to a mailing list
>from each subscriber, then they'd have to send out a seperate
>mail to each one. This would be *very* easy to implement.

  You think changing the SMTP protocol is *easy* to implement, eh,
Beavis?

Steve Baker

Murray Watson  <JunkDTectr@adelphia.net> wrote:
> 
> It's not a spam solution, it's a forgery prevention tool and it's a 
> no-lose situation for both sender and receiver.

No loss, and incremental benefit. 

It's worth doing just for the little bit it helps, and the more 
domains that use it, the more it helps.

> The targeted advantage is not for the receiver but the sender.  I'm 
> really surprised that banks and phishing targets like paypal haven't 
> jumped on immediately.  A simple line of text in their DNS will help 
> thwart financial phishers and reduce their customer service costs.

It's certainly helped me. There's at least one spammer out there
forging any address that appears in NANAE. I've noticed a definite
decrease in bounces since publishing an SPF record.

> Several years back Juno.com was almost driven to extinction because 
> they were the top forged domain.  @juno.com had become a "spam 
> signature".

$ host -t txt juno.com
juno.com text "v=spf1 ptr:untd.com ptr:netzero.net ptr:juno.com ip4:64.136.0.0/18 ?all"
juno.com text "primary"

> There are some side effects that will impact spam, some things twice 
> removed.  I think as a result, some trojans will evolve to attempt to 
> hijack the local Outlook to send spam, this will result in consumer 
> networks like Adelphia cleaning up their trojaned clients more 
> quickly.

And this is exactly the point. Spam is a problem of externalized 
costs. The costs won't disappear, but if you can push them onto the 
parties that actually have the power to stop it, it will stop.

jason

-- 
"Listen, my boy, I can't abide children. I know it's the style nowadays to
make a terrible fuss over you - but I don't go for it. As far as I'm concerned,
they're no good for anything but screaming, torturing people, breaking things,
smearing books with jam and tearing the pages."  - The Neverending Story

Chris F.A. Johnson wrote:
> On 2004-09-20, Rex Karz wrote:
> 
>>The concept of Bcc: predates electronic mail of any sort. The 
>>concept of Bcc: comes from manual, paper office procedure, as does 
>>Cc:. The meaning of Cc: is "courtesy copy",
> 
> 
>     In fact, "cc:" means "copies", "c:" is "copy".
> 
>     The word "courtesy" was introduced by people who didn't know the
>     meaning, and retrofitted an acronym.

You're both wrong, cc means carbon copy. It's name derives from the
carbon paper used to produce the copy.

Paul

On 2004-09-20, Paul Black wrote:
> Chris F.A. Johnson wrote:
>> On 2004-09-20, Rex Karz wrote:
>> 
>>>The concept of Bcc: predates electronic mail of any sort. The 
>>>concept of Bcc: comes from manual, paper office procedure, as does 
>>>Cc:. The meaning of Cc: is "courtesy copy",
>> 
>> 
>>     In fact, "cc:" means "copies", "c:" is "copy".
>> 
>>     The word "courtesy" was introduced by people who didn't know the
>>     meaning, and retrofitted an acronym.
>
> You're both wrong, cc means carbon copy. It's name derives from the
> carbon paper used to produce the copy.

    "Carbon copy" is another retrofitted expansion. As a secretarial
    guide will tell you (though they may have degraded themselves to
    include these neologisms by now), "c:" means copy, "cc:" means
    copies.

-- 
    Chris F.A. Johnson                  http://cfaj.freeshell.org/shell
    ===================================================================
    My code (if any) in this post is copyright 2004, Chris F.A. Johnson
    and may be copied under the terms of the GNU General Public License

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2004-09-20, Paul Black <nospam@nospam.saturnine.org.uk> wrote:
> Chris F.A. Johnson wrote:
>> 
>>     In fact, "cc:" means "copies", "c:" is "copy".
>
> You're both wrong, cc means carbon copy. It's name derives from the
> carbon paper used to produce the copy.

I can't say that Chris is correct, but I do recall that back in the day,
in school we were taught to refer to one page as p. 21, and multiple
pages as pp. 22-34.  Perhaps cc: comes from the same context.

I don't see how cc: could possibly stand for "courtesy copy".  Sometimes
I use it to get the To: person in trouble by Cc:ing his boss, which hardly
demonstrates courtesy, since the To: person is in trouble and the boss
gets more work to do.  ;-)

- --keith

- -- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBTzqfhVcNCxZ5ID8RAoyRAKCb6pthVgTvlEUfp6ox61bA41TEEACfRXG7
84ZMdnIqsqJpcs7Wk8rGq9A=
=Jkpu
-----END PGP SIGNATURE-----

Chris F.A. Johnson wrote:
> On 2004-09-20, Rex Karz wrote:
> 
>>The concept of Bcc: predates electronic mail of any sort. The 
>>concept of Bcc: comes from manual, paper office procedure, as does 
>>Cc:. The meaning of Cc: is "courtesy copy",
> 
> 
>     In fact, "cc:" means "copies", "c:" is "copy".
> 
>     The word "courtesy" was introduced by people who didn't know the
>     meaning, and retrofitted an acronym.
> 

Actually, as far as I remember, "cc:" meant
"carbon copy" (but I could be wrong).

Way back when, in the stone ages with typewriters,
people (secretaries) would actually type a single
copy with carbon paper betwen sheets of plain paper
so that the impression of the keys came through
all the sheets.  (This was also before the days
of photocopiers.)  Most sane folks would limit
cc's to, at most, about 4 *important* people.

Only later, when carbon paper was a thing of the
past, did the term change to "copies" or, in come
people's minds, to "courtesy copy."

I had never heard of "bcc" until much later,
but that's me.  There may have folks who said
to their typists, "oh, by the way, make another
carbon for Mr. Smith, but don't put him on
the CC list."

NPL

-- 
"It is impossible to make anything foolproof
because fools are so ingenious"
  - A. Bloch

On Mon, 20 Sep 2004 20:14:27 +0100, Blane Bramble
<blane@spamguard.lyzard.net> wrote:


> "Alan Connor" <zzzzzz@xxx.yyy> wrote in message
> news:Obx3d.437$g42.228@newsread3.news.pas.earthlink.net...
>
>> On Mon, 20 Sep 2004 09:33:10 +0100, chris-usenet@roaima.co.uk
>> <chris-usenet@roaima.co.uk> wrote:
>>
>>
>> I'd favor eliminating the Bcc header too: If someone wants to
>> keep the names of other subscribers to a mailing list from
>> each subscriber, then they'd have to send out a seperate mail
>> to each one. This would be *very* easy to implement.
>
>
> I might be getting hold of the wrong end of the stick, but the
> "BCC header" has nothing to do with email delivery - delivery
> addresses are part of the SMTP envelope, and nothing to do
> with any of the headers (which are part of the content). From
> a protocol point of view there is no correlation between the
> recipient requested by SMTP and the information about who the
> message is to within the message headers.
>
>

Okay. Thanks. Is there any practical way to *demand* (by the rec-
eiving MTA) a correspondence between the envelope addresses and
the content addresses?

If there is, *then* we could eliminate the Bcc header :-))

AC

-- 
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb

Alan Connor wrote:

> Okay. Thanks. Is there any practical way to *demand* (by the rec-
> eiving MTA) a correspondence between the envelope addresses and
> the content addresses?

Sure. A lot of MTAs (at least Postfix) can do filtering on
the content or even just on the header. As soon you're able
to do that, than it's "easy" to implement something like this.

HOWEVER, be aware that right now such a measure would make it
impossible to receive from mailinglists and newsletters. Those
close to always use a "Bcc mechanism" to mail the mails.

And because of that, I don't see that a mail provider will
implement such a feature w/o risking to alienate the customers.

Alexander Skwar
-- 
The scum also rises.
		-- Dr. Hunter S. Thompson
������������������������������������������������������������������������

Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> On 2004-09-20, Paul Black <nospam@nospam.saturnine.org.uk> wrote:
> > Chris F.A. Johnson wrote:
> >> 
> >>     In fact, "cc:" means "copies", "c:" is "copy".
> >
> > You're both wrong, cc means carbon copy. It's name derives from the
> > carbon paper used to produce the copy.

> I can't say that Chris is correct, but I do recall that back in the day,
> in school we were taught to refer to one page as p. 21, and multiple
> pages as pp. 22-34.  Perhaps cc: comes from the same context.

I can only say that 20 years ago the man page for mail used to refer to
 cc: as "carbon copy", and bcc: as "blind crbon copy".

Well, whadya know, it still does.

    ~bname ...
             Add the given names to the list of carbon copy recipients but do
             not make the names visible in the Cc: line ("blind" carbon copy).


Peter

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-20893-1095719903-0003
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Beavis writes:

> Okay. Thanks. Is there any practical way to *demand* (by the rec-
> eiving MTA) a correspondence between the envelope addresses and
> the content addresses?

No, Beavis.  SMTP does not work this way.



--=_mimegpg-commodore.email-scan.com-20893-1095719903-0003
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBT1vfx9p3GYHlUOIRArNdAJ9RQsH+QQEe+S69Q8znhhoX5DzsZgCdEGo9
kuZgusBZ8DtSZVecrIndahc=
=WwKa
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-20893-1095719903-0003--

Jonathan de Boyne Pollard sez:
> MW> [SPF is] not a spam solution, [...]
> 
> And indeed this is well known in certain circles, including the MARID 
> working group.
> 
><URL:news://news.gmane.org./20040914064058.GB15185@nic.fr>
><URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-spf-is-harmful.html>
> 
> Nonetheless, it continues to be advertised as such:
> 
> "SPF reduces inbound spam."
> -- <URL:http://spf.pobox.com./execsumm.html>
> 
> "If the message fails SPF tests, it's a forgery.
> That's how you can tell it's probably a spammer."
> -- <URL:http://spf.pobox.com./faq.html>
> (That first sentence is a lie, of course.)
> 
> "Eventually, as SMTP improves its immunity to spam,
> we hope spammers will get discouraged."
> -- <URL:http://spf.pobox.com./faq.html>
> 
> "'Why should SPF succeed when similar proposals have failed
> in the past?'  The spam problem was never as bad in the past
> as it is now."
> -- <URL:http://spf.pobox.com./faq.html>
> 
> "Saving the world from spam is an expensive duty."
> -- <URL:http://spf.pobox.com./donations.html>

Have they figured out how to SPF without breaking SMTP yet?

Dima
-- 
Surely there is a polite way to say FOAD.                        -- Shmuel Metz
"Go forth and multiply".                                         -- Paul Martin

Chris F.A. Johnson <cfajohnson@gmail.com> wrote:
> On 2004-09-20, Rex Karz wrote:
>> The concept of Bcc: predates electronic mail of any sort. The 
>> concept of Bcc: comes from manual, paper office procedure, as does 
>> Cc:. The meaning of Cc: is "courtesy copy",
> 
>    In fact, "cc:" means "copies", "c:" is "copy".

That makes perfect sense.  My reading of it was "carbon copy", since,
once upon a time, carbon paper was used for such copies.

-- 
John Wingate                        Mathematics is the art which teaches
johnww@worldpath.net                one how not to make calculations.
                                                         --Oscar Chisini

"dplatt@radagast.org (Dave Platt)" wrote in news.admin.net-abuse.email:

[sNip]
> It's also technically unenforceable, unless you make a massive set of
> changes to the email infrastructure.  To enforce it, you'd have to
> pass along the entire set of addressees as part of every SMTP
> transaction, as well as listing them in the envelope, so that the
> receiving MTA could check for the presence of "blind" (unlisted)
> addressees.

    	...and that would be a huge privacy concern for obvious reasons.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

On Mon, 20 Sep 2004, Randolf Richardson wrote:

> "Dave Uhring <daveuhring@yahoo.com>" wrote in news.admin.net-abuse.email:
> 
> > On Mon, 20 Sep 2004 05:02:55 +0000, Randolf Richardson wrote:
> > 
> >> Regardless of how I configure my DNS zone to return a different IP 
> >> address for "netware.inter-corporate.com," the root servers will
> >> override this by providing the information specified in the host
> >> record.  This also seems to speed up DNS resolutiona little bit, by the
> >> way, because the root servers don't have to take addition steps to look
> >> up external NS records. 
> > 
> > I also think that someone is putting something over on you:
> > 
> > Non-authoritative answer:
> > Name:   netware.inter-corporate.com
> > Address: 24.87.56.253
> > 
> > Authoritative answers can be found from:
> > inter-corporate.com     nameserver = netware.inter-corporate.com.
> > inter-corporate.com     nameserver = oc48.inter-corporate.com.
> > inter-corporate.com     nameserver = fast01.inter-corporate.com.
> > oc48.inter-corporate.com        internet address = 64.251.89.8
> > fast01.inter-corporate.com      internet address = 64.251.89.88
> > 
> > Suppose you turn off those three DNS servers and then attempt to resolve
> > some host whose zone records are maintained there.
> 
>     	I'm aware of how this is all configured.  Of course, if I turn off my 
> DNS servers and wait for caches to expire, the only items that will resolve 
> are the registered name servers.
> 
>     	I know it works this way too because I've run across a few registered 
> host names that resolved in the past, yet the IPs they resolved to weren't 
> running any DNS servers (queries against them simply timed out).  The only 
> reason I discovered these was when I was troubleshooting eMail delivery 
> problems for clients.

Did you make the queries from your own system or did you use a web-based
DNS lookup that started the DNS query from outside your (and your
customer's) system?

One catch is that your system has to start querying *somewhere* and
the IP address for the nameserver that answers that first DNS query
has to be entered into your system configuration.  (One of the entries
I had to make for my PPP connection is enter the IP addresses for the 
primary and secondary nameservers to use.)  If the IP address of *that*
nameserver is still present in your system configuration and the machine
at that IP address is still providing DNS service (including serving
information from its own zone files), it can still answer your queries
even if the DNS entries for that nameserver are no longer in the root
servers or any server accesible through the root servers.  You may have
been querying an otherwise unreachable nameserver that contained the zone
files for your customer's systems.

So even if ns1.foo.somplace.invalid no longer resolves for others,
if you have the IP address for the ns1.foo.somplace.invalid nameserver
in your configuration and ns1.foo.somplace.invalid still thinks it's
OK, then ns1.foo.somplace.invalid will return the DNS for itself or any
other otherwise unreachable system in its zone files that it thinks it's
authoritive for.  Or your secondary nameserver elsewhere (if you had one)
may have been answering the queries.

One advantage of this is that, even if a major datapipe is cut and the
main DNS servers are unreachable for you (cutting you off from the rest
of the Internet until things are fixed), you can still access other
machines on your own network using the local DNS server in your system
configuration.

One disadvantage is that you may need some way to bypass that nameserver
when you have to in order to troubleshoot DNS problems -- including the
possible need to know the IP addresses of the root nameservers in order
to query them (something that may have to be looked up in advance of
problems and something that may have to be done on a regular[1] basis to
ensure you have correct info).

[1] Since I don't know how often root nameservers change IP addresses,
    "regular" could mean once per week, once per year, once per
    decade, or once per century.  (/me off to read some more and try
    to eliminate some more ignorance.)
-- 
Norman De Forest             http://www.chebucto.ns.ca/~af380/Profile.html
af380@chebucto.ns.ca            [=||=]            (A Speech Friendly Site)
"One suspects that by now even *Nigerians* have Nigeria blacklisted ;)." 
-- Jim Seymour on 419 scams, news.admin.net-abuse.email, Tue, Nov 19, 2002

"Alexander Skwar <from@alexander.skwar.name>" wrote in
news.admin.net-abuse.email: 

> Randolf Richardson wrote:
[sNip - sensible commentary]
>> It's really a matter of allowing people to protect others' privacy, and
>> to take this option away from end users would set a very bad precedent.
> 
> You misunderstood him. Instead of writing a mail which has

    	I think you may be correct (thanks for pointing this out).

> To: me@adress.is.invalid
> 
> He wants every mail to have
> 
> To: him@adress.is.not.invalid
> 
> Now, to protect the privacy, this might mean, that every mail has
> just one recipient, which would increase the number of mails that

    	Additional cost (time & money) to normal users.  This is not good.

> have to be sent by a spammer. Right now, with Bcc:, a spammer only
> has to deliver 1 (one) mail and have the MTA deliver it to every
> "Bcc adress". With no bcc, the spammer would need to deliver as
> many mails as there are recipients.

    	Obviously it won't help to put a stop to spam once all the spammers 
have updated their spamware, thus making it a wasted effort in this regard.

    	But all this begs the question "what's the real reason someone would 
want to change the way SMTP headers used in this way?"  I suspect the 
answer may be that the SMTP server being used doesn't include the real 
recipient information in either an "X-Envelope-To:" or a "Received:" SMTP 
header, and so they're unable to filter based on the real recipient eMail 
address.

    	I've gotten business from customers with wildcard accounts who weren't 
happy with their ISPs because they couldn't determine which recipients to 
forward messages to for a particular eMail list that a number of their 
users signed up for.  After they switched to my system, which injects an 
"X-Envelope-To: someone@example.com" SMTP header, their problem was solved.

    	One of my guesses would be that the person asking for this is in a 
similar predicament, and they're trying to find an easy fix for it (easy 
for them, as far as they're concerned anyway).

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

"Alan Connor <zzzzzz@xxx.yyy>" wrote in news.admin.net-abuse.email:

[sNip]
> Okay. Thanks. Is there any practical way to *demand* (by the rec-
> eiving MTA) a correspondence between the envelope addresses and
> the content addresses?
> 
> If there is, *then* we could eliminate the Bcc header :-))

    	Count me out.

    	Many of the eMail lists I chose to subscribe to use this mechanism 
when distributing a posting to the membership without changing the 
"From:," "To:," and "Cc:" SMTP headers, thus making it easy for recipients 
to know who the message was really addressed to.  Change the "To:" field 
from the eMail list's posting address to each individual recipient, and the 
membership will be confused.

    	In the context of eMail lists alone, removing the BCC mechanism will 
already cause too many problems.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

"Steve Baker <bakesph@comcast.net>" wrote in news.admin.net-abuse.email:

> On Mon, 20 Sep 2004 09:14:22 GMT, Alan Connor <zzzzzz@xxx.yyy> wrote:
> 
>>I'd favor eliminating the Bcc header too: If someone wants
>>to keep the names of other subscribers to a mailing list
>>from each subscriber, then they'd have to send out a seperate
>>mail to each one. This would be *very* easy to implement.
> 
>   You think changing the SMTP protocol is *easy* to implement, eh,
> Beavis?

    	If I were to design an SMTP alternative/replacement, a BCC mechanism 
would definitely be a part of it.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

Alan Connor wrote:

> On 19 Sep 2004 17:26:02 GMT, Cameron L. Spitzer wrote:
> 
> 
>>In article <2Ai3d.4519$bL1.86900@news20.bellglobal.com>, John
>>Doe wrote:
>>
>>
>>>Sender ID got turned down by both the IETF and Time Warner/AOL
>>>as a way to solve the spam problem. The issue has apparently
>>>nothing to do with the technical merits of MSFT's solution,
>>>but rather, with concerns of these parties and the open source
>>>community that MSFT would somehow use this to get some sort of
>>>leverage, based on past MSFT's business practices.
>>
>>Of course.  M~FT needs to replace the public SMTP email system
>>with something that hinders its competition and generates a
>>revenue stream.  Adding a patented feature does exactly that.
>>
>>
>>
>>>Here's a take on the subject from TF:
>>>
>>>http://gruia.blogware.com/blog/_archives/2004/9/17/142790.html
>>>
>>>Question: is there something being developed on this front
>>>by any Linux vendor or third-pary open source developer?  I
>>>imagine the answer is "yes",
>>
>>Sender Policy Framework http://spf.pobox.com/
>>
> 
> 
> Looks promising. From that site:
> 
> <quote>
> 
> In this example, AOL.com is the sending domain, and
> pobox.com is the receiver.
> 
> AOL publishes an SPF record, specifying which computers on
> the Internet can send mail as user@aol.com
> 
> 1. When a real AOL user sends mail, pobox.com receives the
> message from an AOL server. 
> 
> 2. Pobox checks AOL's SPF record, to make sure the server is allo
> wed to send mail from AOL.
> 3. The server is listed, so Pobox gives the message a pass.
> 
> (Expensive content-based spam checks can be bypassed, saving reso
> urces on the receiver side.)
> 
> -------------
> 
> 1. When a spammer forges mail from AOL, Pobox receives the
>  messages from an outside server.
> 
> 2. Pobox checks AOL's SPF record.
> 
> 3. The server is not listed, so Pobox gives the message a
> fail.
> 
> (Expensive content-based spam checks can be bypassed, saving reso
> urces on the receiver side.)
> 
> ....
> 
> If you do get spam that passed an SPF check, then you know you
> should hold the sending domain responsible for the message.
> 
> 

We have a variant on this that people may find interesting, by applying a 'default' spf
rule to all domains that don't have real ones the system becomes a lot tighter, and with failures
we give a reject at the recipient stage that includes instructions
for enabling delivery so failures are not critical

See http://netwinsite.com/spf.htm


	ChrisP.

c> [SPF] does have disadvantages (header rewriting required for email
c> forwarding, [...]

No, that's Sender ID.  SPF involves envelope rewriting.

Randolf Richardson wrote:
> "dplatt@radagast.org (Dave Platt)" wrote in news.admin.net-abuse.email:
> 
> [sNip]
> 
>>It's also technically unenforceable, unless you make a massive set of
>>changes to the email infrastructure.  To enforce it, you'd have to
>>pass along the entire set of addressees as part of every SMTP
>>transaction, as well as listing them in the envelope, so that the
>>receiving MTA could check for the presence of "blind" (unlisted)
>>addressees.
> 
> 
>     	...and that would be a huge privacy concern for obvious reasons.

"Obvious reasons"? Why would that be? A recipient would see only
his name/adress. Yes, that of course makes the number of mails sent
out a whole lot bigger.

Alexander Skwar
-- 
miracle:  an extremely outstanding or unusual event, thing, or accomplishment.
-- Webster's Dictionary
������������������������������������������������������������������������

Randolf Richardson wrote:
> "Alexander Skwar <from@alexander.skwar.name>" wrote in
> news.admin.net-abuse.email: 
> 
> 
>>Randolf Richardson wrote:
> 
> [sNip - sensible commentary]
> 
>>>It's really a matter of allowing people to protect others' privacy, and
>>>to take this option away from end users would set a very bad precedent.
>>
>>You misunderstood him. Instead of writing a mail which has
> 
> 
>     	I think you may be correct (thanks for pointing this out).
> 
> 
>>To: me@adress.is.invalid
>>
>>He wants every mail to have
>>
>>To: him@adress.is.not.invalid
>>
>>Now, to protect the privacy, this might mean, that every mail has
>>just one recipient, which would increase the number of mails that
> 
> 
>     	Additional cost (time & money) to normal users.  This is not good.

Well, yes, that's right, however, how many normal users would
be affected by this?

Nah, it's rather that mailing lists (even the legitemate ones)
would suffer gravely from this.

>>have to be sent by a spammer. Right now, with Bcc:, a spammer only
>>has to deliver 1 (one) mail and have the MTA deliver it to every
>>"Bcc adress". With no bcc, the spammer would need to deliver as
>>many mails as there are recipients.
> 
>     	Obviously it won't help to put a stop to spam once all the spammers 
> have updated their spamware, thus making it a wasted effort in this regard.

No, it's not *wasted*. Everything that makes it harder for spammers
is a good thing - if the bad effects on normal users are small enough
to be bearable.

Alexander Skwar
-- 
A narcissist is someone better looking than you are.
		-- Gore Vidal
������������������������������������������������������������������������

Sam wrote:
> Beavis writes:
> 
> 
>>Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>eiving MTA) a correspondence between the envelope addresses and
>>the content addresses?
> 
> 
> No, Beavis.  SMTP does not work this way.

Wrong. THere are   MTAs, that do checks AFTER the . has been sent
and before the mail is queued.

Alexander Skwar
-- 
 One of Bender's kids: Can we have Bender burgers again?
 Bender: No, the cat shelter's onto me.
������������������������������������������������������������������������

Randolf Richardson wrote:

>     	Many of the eMail lists I chose to subscribe to use this mechanism 
> when distributing a posting to the membership

Yes.

> without changing the 
> "From:," "To:," and "Cc:" SMTP headers, thus making it easy for recipients 
> to know who the message was really addressed to.  Change the "To:" field 
> from the eMail list's posting address to each individual recipient, and the 
> membership will be confused.

Why? To protect privacy, the To: would contain (in my case) JUST
lists@alexander.skwar.name, and nothing else (well, my Realname maybe *G*).
What's confusing about this?

Alexander Skwar
-- 
New York now leads the world's great cities in the number of people around
whom you shouldn't make a sudden move.
t		-- David Letterman
������������������������������������������������������������������������

On Mon, 20 Sep 2004 17:38:25 -0500, Sam <sam@email-scan.com> wrote:

>Beavis writes:
>
>> Okay. Thanks. Is there any practical way to *demand* (by the rec-
>> eiving MTA) a correspondence between the envelope addresses and
>> the content addresses?
>
>No, Beavis.  SMTP does not work this way.
>

Don't let your hatred of AC get in the way of your normally astute
thinking.  SMTP _could_ work this way.  The protocol (as you know)
could go

EHLO...
MAIL FROM:...
RCPT TO....
DATA...
..

At the "." the MTA could kick a 550 or 553 message: "DATA and RCPT TO
don't match."

But, of course, more than half the mail in the world would never make
it to the destination.   So I agree with your overall assessment, it
is a Beavis suggestion.


Mark Marcus
Protect Your Email Address and Make Money too!
http://www.xhome.org  My Sales Code is 22819

On 2004-09-20, P.T. Breuer wrote:
> Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>
>> On 2004-09-20, Paul Black <nospam@nospam.saturnine.org.uk> wrote:
>> > Chris F.A. Johnson wrote:
>> >> 
>> >>     In fact, "cc:" means "copies", "c:" is "copy".
>> >
>> > You're both wrong, cc means carbon copy. It's name derives from the
>> > carbon paper used to produce the copy.
>
>> I can't say that Chris is correct, but I do recall that back in the day,
>> in school we were taught to refer to one page as p. 21, and multiple
>> pages as pp. 22-34.  Perhaps cc: comes from the same context.
>
> I can only say that 20 years ago the man page for mail used to refer to
>  cc: as "carbon copy", and bcc: as "blind crbon copy".
>
> Well, whadya know, it still does.
>
>     ~bname ...
>              Add the given names to the list of carbon copy recipients but do
>              not make the names visible in the Cc: line ("blind" carbon copy).

   So the mistake is at least 20 years old, and has been perpetuated.

-- 
    Chris F.A. Johnson                  http://cfaj.freeshell.org/shell
    ===================================================================
    My code (if any) in this post is copyright 2004, Chris F.A. Johnson
    and may be copied under the terms of the GNU General Public License

Chris F.A. Johnson wrote:
> On 2004-09-20, Paul Black wrote:
> 
>>Chris F.A. Johnson wrote:
>>
>>>On 2004-09-20, Rex Karz wrote:
>>>
>>>
>>>>The concept of Bcc: predates electronic mail of any sort. The 
>>>>concept of Bcc: comes from manual, paper office procedure, as does 
>>>>Cc:. The meaning of Cc: is "courtesy copy",
>>>
>>>
>>>    In fact, "cc:" means "copies", "c:" is "copy".
>>>
>>>    The word "courtesy" was introduced by people who didn't know the
>>>    meaning, and retrofitted an acronym.
>>
>>You're both wrong, cc means carbon copy. It's name derives from the
>>carbon paper used to produce the copy.
> 
> 
>     "Carbon copy" is another retrofitted expansion.

Evidence? Everything I've found, including the OED, states "carbon copy".

Paul

In news.admin.net-abuse.email - article <c1.01.2srMcw
$5AJ@J.de.Boyne.Pollard.localhost>, on Mon, 20 Sep 2004 15:43:15 GMT, 
Jonathan de Boyne Pollard says...
> MW> [SPF is] not a spam solution, [...]
> 
> And indeed this is well known in certain circles, including the MARID 
> working group.

Well then, there you have it.  We agree on 1 thing straight away.

> <URL:news://news.gmane.org./20040914064058.GB15185@nic.fr>

Sorry, can't readily access that.

> <URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-spf-is-harmful.html>

That needs some work, looks like it may have been authored about the 
time I first mentioned using DNS to determine authorized servers here 
in NANAE 6/1/2000.  A lot has changed since then.

> Nonetheless, it continues to be advertised as such:
> 
> "SPF reduces inbound spam."
> -- <URL:http://spf.pobox.com./execsumm.html>

Calling that "advertise" is a stretch.  Nowhere do they indicate it's 
a spam solution, they do point out how spam may be reduced by SPF but 
they also point out how spammers will mitigate the damage, the stated 
purpose remains, a forgery prevention tool.  The truth is, most 
people haven't been the victim of forgeries so they tend to minimize 
that and focus on _spam_ inflating it out of context.  If you have 
been victimized by forgeries, it's devastating and SPF's merits for 
forgery prevention stand on their own.  It's not the best, most 
secure method of forgery prevention but it's quick, easy, here and 
now.

It will reduce spam but it's not a spam solution.  You need to 
maintain the statement qualifiers, "A significant majority of spam is 
forged. SPF allows your mail servers to easily distinguish forgeries 
from real mail".  The assertion is forgeries=spam  
reduce_forgeries=reduce_spam.  I think that's reasonable.

> "If the message fails SPF tests, it's a forgery.
> That's how you can tell it's probably a spammer."
> -- <URL:http://spf.pobox.com./faq.html>
> (That first sentence is a lie, of course.)

Barring transient failures, and the insignificant amount of malicious 
forging done by non-spammers, the assertion spf_fail=forgery=spam 
will return true.

> "Eventually, as SMTP improves its immunity to spam,
> we hope spammers will get discouraged."
> -- <URL:http://spf.pobox.com./faq.html>

Nothing to do with SPF.

You obviously read the link I pointed to since that statement is from 
the section titled "SPF doesn't really STOP spam, does it?"
http://spf.pobox.com/faq.html#churn
Where they cite many ways spammers will navigate around SPF.  Hardly 
advertising SPF as a spam solution.
 
> "'Why should SPF succeed when similar proposals have failed
> in the past?'  The spam problem was never as bad in the past
> as it is now."
> -- <URL:http://spf.pobox.com./faq.html>

It depends on what you perceive the proposal to be.  The home page 
has this :
"SPF: Sender Policy Framework 
The Anti-Forgery solution
That's making the world a
Safer place for email."

This is in the most predominant position on their home page and this 
seems to me to be their proposal:

"What is SPF? 
 SPF is Sender Policy Framework (link to #howworks)
SPF fights email address forgery and makes it easier to identify 
spams, worms, and viruses.
Domain owners identify sending mail servers in DNS. 
SMTP receivers verify the envelope sender address against this 
information, and can distinguish legitimate mail from spam before any 
message data is transmitted."

http://spf.pobox.com/faq.html#howworks
You need to read "The Rationale: SPF Explained" which further 
explains what the "proposal" is.

To state that the spam problem is at it's worst when the proposal 
will have an effect on how spammers operate by further corralling 
spammers into a smaller more readily identifiable space is 
reasonable.

> "Saving the world from spam is an expensive duty."
> -- <URL:http://spf.pobox.com./donations.html>

Yup.

As the various media authors have done, you've read into SPF that its 
purpose is to be a solution to spam.  It's not and they're not 
representing it as such.  They've stated their goal and methods and 
presented workarounds/fixes and patches for various technical issues.  
In the process they've indicated how it will address one of the most 
common uses of such email forgery today, spam, along with other 
common places malicious forgeries are used as indicated in "What is 
SPF?" above.

In news.admin.net-abuse.email - article 
<g0cnic.8mk.ln@shell.gaydeceiver.com>, on Mon, 20 Sep 2004 12:45:20 -
0700, Jason Steiner says...
> Murray Watson  <JunkDTectr@adelphia.net> wrote:
> > 
> > It's not a spam solution, it's a forgery prevention tool and it's a 
> > no-lose situation for both sender and receiver.
> 
> No loss, and incremental benefit. 
> 
> It's worth doing just for the little bit it helps, and the more 
> domains that use it, the more it helps.

The effort to publish spf records for your domain to minimize the 
possibility of that domain being used for someone else's purposes is 
a no brainer.  If there's a lock on my door, I lock it but then I'm a 
fool, I use seatbelts also.

Installing spf on my MX to reject just 1 forged freemail spam, virus 
or damned 419 scam a day is worth the effort.

> > The targeted advantage is not for the receiver but the sender.  I'm 
> > really surprised that banks and phishing targets like paypal haven't 
> > jumped on immediately.  A simple line of text in their DNS will help 
> > thwart financial phishers and reduce their customer service costs.
> 
> It's certainly helped me. There's at least one spammer out there
> forging any address that appears in NANAE. I've noticed a definite
> decrease in bounces since publishing an SPF record.
> 
> > Several years back Juno.com was almost driven to extinction because 
> > they were the top forged domain.  @juno.com had become a "spam 
> > signature".
> 
> $ host -t txt juno.com
> juno.com text "v=spf1 ptr:untd.com ptr:netzero.net ptr:juno.com ip4:64.136.0.0/18 ?all"
> juno.com text "primary"

They survived then merged but they were the big dog in their day.  
The original free email provider.

> > There are some side effects that will impact spam, some things twice 
> > removed.  I think as a result, some trojans will evolve to attempt to 
> > hijack the local Outlook to send spam, this will result in consumer 
> > networks like Adelphia cleaning up their trojaned clients more 
> > quickly.
> 
> And this is exactly the point. Spam is a problem of externalized 
> costs. The costs won't disappear, but if you can push them onto the 
> parties that actually have the power to stop it, it will stop.
> 
> jason
> 
> 

In news.admin.net-abuse.email - article <Xns9569E13EBF5F2rr8xca@
24.64.223.211>, on Mon, 20 Sep 2004 05:02:55 GMT, Randolf Richardson 
says...
>     	Regardless of how I configure my DNS zone to return a different IP 
> address for "netware.inter-corporate.com," the root servers will override 
> this by providing the information specified in the host record.  This also 
> seems to speed up DNS resolutiona little bit, by the way, because the root 
> servers don't have to take addition steps to look up external NS records.

Cricket disagrees.

http://www.menandmice.com/9000/9320_DNS_Corner_Q&A/93_Q&A_033.html

In news.admin.net-abuse.email - article 
<pan.2004.09.20.17.07.43.58013@yahoo.com>, on Mon, 20 Sep 2004 
12:07:46 -0500, Dave Uhring says...
> On Mon, 20 Sep 2004 09:40:38 -0700, Murray Watson wrote:
> 
> > Dave Uhring <daveuhring@yahoo.com> wrote in message news:<pan.2004.09.20.03.26.57.116887@yahoo.com>...
> >> On Sun, 19 Sep 2004 23:03:30 -0400, Murray Watson wrote:
> >> 
> >> > In news.admin.net-abuse.email - article 
> >> > <pan.2004.09.20.02.15.38.117238@yahoo.com>, on Sun, 19 Sep 2004 
> >> > 21:15:42 -0500, Dave Uhring says...
> >> >> On Sun, 19 Sep 2004 21:56:51 -0400, Murray Watson wrote:
> >> >> 
> >> >> > We've got to educate them on how to remove registered name servers.
> 
> >> What is a "registered name server" which you want removed?
> 
> > For the GTLD servers to function as a dns server of sorts for
> > hotmail.com to provide IP addresses of hotmail.com's dns servers,
> > hotmail.com must have registered specific hostnames and their
> > corresponding IP address as well as what the designated nameserver
> > names are for the domain hotmail.com.  Hence the name "registered
> > host".
> 
> Now if Microsfot's hotmail.com domain were revoked would its domain name
> still be associated with ns[1|2|3|4].hotmail.com and further associated
> with IP addresses assigned to those nameservers at the GTLD servers?
> 
> If not then just what does this mean "We've got to educate them on how
> to remove registered name servers."?

As I said, 
It's in this thread Message-ID: <16d694b9.0409131408.216e49c4@posting.google.com>

http://groups.google.com/groups?&threadm=16d694b9.0409131408.216e49c4%40posting.google.com

c> [SPF] does have disadvantages (header rewriting required for email
c> forwarding, [...]

Jonathan de Boyne Pollard <J.deBoynePollard@tesco.net> wrote:
> No, that's Sender ID.  SPF involves envelope rewriting.

Apologies. I mis-remembered my reading of the spec on pobox.com
Chris

Alexander Skwar writes:
> A recipient would see only his name/adress.

Whoever controls the receiving MTA sees whatever he wants to see.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, Wisconsin

"Blane Bramble" <blane@spamguard.lyzard.net> writes:
>I might be getting hold of the wrong end of the stick, but the "BCC header"
>has nothing to do with email delivery - delivery addresses are part of the

That's right, in that there's no BCC transaction in SMTP. If beavis is
saying that BCCs are a problem for him, it's because his dumbass C/R system
can't handle them without spamming mailing lists. Remember, It's all about
Alan Connor. *
-- 
* PV   something like badgers--something like lizards--and something
       like corkscrews.

Mark Marcus <mark@agentnews.sales.xhome.us> writes:
>thinking.  SMTP _could_ work this way.  The protocol (as you know)
>At the "." the MTA could kick a 550 or 553 message: "DATA and RCPT TO
>don't match."
>
>But, of course, more than half the mail in the world would never make
>it to the destination.   So I agree with your overall assessment, it
>is a Beavis suggestion.

Even lacking BCCs, any message sent to more than one mailserver will ALWAYS
have a mismatch between the SMTP recipients and the addressees. Apparently,
Beavis thinks that every mailserver gets every RCPT TO. Dumb. *
-- 
* PV   something like badgers--something like lizards--and something
       like corkscrews.

Paul Vader wrote:
> Mark Marcus <mark@agentnews.sales.xhome.us> writes:
> 
>>thinking.  SMTP _could_ work this way.  The protocol (as you know)
>>At the "." the MTA could kick a 550 or 553 message: "DATA and RCPT TO
>>don't match."
>>
>>But, of course, more than half the mail in the world would never make
>>it to the destination.   So I agree with your overall assessment, it
>>is a Beavis suggestion.
> 
> 
> Even lacking BCCs, any message sent to more than one mailserver will ALWAYS
> have a mismatch between the SMTP recipients and the addressees. Apparently,
> Beavis thinks that every mailserver gets every RCPT TO. Dumb. *

What are you talking about?

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

On 2004-09-21, Paul Black wrote:
> Chris F.A. Johnson wrote:
>> 
>>     "Carbon copy" is another retrofitted expansion.
>
> Evidence? Everything I've found, including the OED, states "carbon copy".

    The evidence is in all the books I read 30 to 40 years ago on
    writing business letters; I don't have any left.

-- 
    Chris F.A. Johnson                  http://cfaj.freeshell.org/shell
    ===================================================================
    My code (if any) in this post is copyright 2004, Chris F.A. Johnson
    and may be copied under the terms of the GNU General Public License

On Tue, 21 Sep 2004 19:39:18 +0000, Chris F.A. Johnson wrote:

> On 2004-09-21, Paul Black wrote:

>> Evidence? Everything I've found, including the OED, states "carbon copy".
> 
>     The evidence is in all the books I read 30 to 40 years ago on
>     writing business letters; I don't have any left.

When I went through the US Army's clerical training school 43 years ago
cc: meant "carbon copy".  The copies were indeed carbon copies, too, since
there were no photocopy machines available.

"Alexander Skwar <from@alexander.skwar.name>" wrote in news.admin.net-
abuse.email:

> Randolf Richardson wrote:
> 
>> "dplatt@radagast.org (Dave Platt)" wrote in news.admin.net-abuse.email:
>> 
>>>It's also technically unenforceable, unless you make a massive set of
>>>changes to the email infrastructure.  To enforce it, you'd have to
>>>pass along the entire set of addressees as part of every SMTP
>>>transaction, as well as listing them in the envelope, so that the
>>>receiving MTA could check for the presence of "blind" (unlisted)
>>>addressees.
>> 
>> ...and that would be a huge privacy concern for obvious reasons.
> 
> "Obvious reasons"? Why would that be? A recipient would see only
> his name/adress. Yes, that of course makes the number of mails sent
> out a whole lot bigger.

    	Yes, obvious to those who know how SMTP is used to transport eMail 
messages, but I'll describe it quickly for you anyway:

    	If a user decides to send an eMail to a group of people they know, and 
some of those people operate SMTP servers themselves, then that would 
defeat the whole purpose of a "blind courtesy copy" since those SMTP server 
operators could obviously have the option to find out who's in the BCC list 
by simply looking at "the entire set of addresses" that were "passed 
along" "as part of every SMTP transaction."

    	Now, for a mailing list with, let's say, ~10,000 subscribers, in most 
cases "the entire set of addresses" would consume more bandwidth than most 
messages (assuming a typical discussions-oriented mailing list such as 
Spam-L, BugTraq, etc.).  In these cases, the suggested approach above would 
obviously be counter-productive in addition to the obvious privacy concerns 
for those who prefer to just read messages without ever posting anything.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

"Alexander Skwar <from@alexander.skwar.name>" wrote in
news.admin.net-abuse.email: 

> Randolf Richardson wrote:
> 
>> "Alexander Skwar <from@alexander.skwar.name>" wrote in
>> news.admin.net-abuse.email: 
[sNip]
>>>To: me@adress.is.invalid
>>>
>>>He wants every mail to have
>>>
>>>To: him@adress.is.not.invalid
>>>
>>>Now, to protect the privacy, this might mean, that every mail has
>>>just one recipient, which would increase the number of mails that
>> 
>> 
>>          Additional cost (time & money) to normal users.  This is not
>>          good. 
> 
> Well, yes, that's right, however, how many normal users would
> be affected by this?

    	Every user who sends eMails in this way would be affected.  Not 
everyone gets consistent performance from their internet connection (and 
then there are the dial-up users who would really notice).

    	Of course, if additional bandwidth (part of the "cost" factor) wasn't 
an issue (in addition to the others), then spam wouldn't be an issue 
either.

> Nah, it's rather that mailing lists (even the legitemate ones)
> would suffer gravely from this.

    	Mailing lists would suffer more than a typical user, but the user 
would also suffer with additional mailing list reliability issues because 
the mailing list owners may have to cut expenses in hardware in order to 
make up for the extra costs associated with bandwidth consumption.

>>>have to be sent by a spammer. Right now, with Bcc:, a spammer only
>>>has to deliver 1 (one) mail and have the MTA deliver it to every
>>>"Bcc adress". With no bcc, the spammer would need to deliver as
>>>many mails as there are recipients.
>> 
>> Obviously it won't help to put a stop to spam once all the spammers 
>> have updated their spamware, thus making it a wasted effort in this
>> regard. 
> 
> No, it's not *wasted*. Everything that makes it harder for spammers
> is a good thing -

    	I agree with that.

> if the bad effects on normal users are small enough to be bearable.

    	This doesn't even apply here because sacrificing privacy is not what I 
consider "small enough to be bearable."  My guess is that a lot of people 
probably agree with me on this specific point [about protecting privacy].

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
news.admin.net-abuse.email: 

> Paul Vader wrote:
[sNip]
>> Even lacking BCCs, any message sent to more than one mailserver will
>> ALWAYS have a mismatch between the SMTP recipients and the addressees.
>> Apparently, Beavis thinks that every mailserver gets every RCPT TO.
>> Dumb. * 
> 
> What are you talking about?

    	Facts (and Paul Vader is absolutely right).  This is how SMTP servers 
work.  Read the relevant RFCs for more details if you don't agree.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

"Alexander Skwar <from@alexander.skwar.name>" wrote in
news.admin.net-abuse.email: 

> Randolf Richardson wrote:
[sNip]
>> without changing the 
>> "From:," "To:," and "Cc:" SMTP headers, thus making it easy for
>> recipients to know who the message was really addressed to.  Change the
>> "To:" field from the eMail list's posting address to each individual
>> recipient, and the membership will be confused.
> 
> Why? To protect privacy, the To: would contain (in my case) JUST
> lists@alexander.skwar.name, and nothing else (well, my Realname maybe
> *G*). What's confusing about this?

    	As a recipient of any given eMail list, I prefer to know if the 
mailing list was addressed in "To:," "Cc:," or "BCc:" (not at all).

    	Ditto for private eMail.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

"pv+usenet@pobox.com (Paul Vader)" wrote in news.admin.net-abuse.email:

> "Blane Bramble" <blane@spamguard.lyzard.net> writes:
> 
>>I might be getting hold of the wrong end of the stick, but the "BCC header"
>>has nothing to do with email delivery - delivery addresses are part of the
> 
> That's right, in that there's no BCC transaction in SMTP. If beavis is
> saying that BCCs are a problem for him, it's because his dumbass C/R system
> can't handle them without spamming mailing lists. Remember, It's all about
> Alan Connor. *

    	That means the mechanism is broken because it's making incorrect 
assumptions.  I'm wondering if he's too lazy to get things fixed on his end, 
and figures that changing the rest of the world may be easier.  =D

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-28713-1095807058-0010
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Alexander Skwar writes:

> Sam wrote:
>> Beavis writes:
>> 
>> 
>>>Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>>eiving MTA) a correspondence between the envelope addresses and
>>>the content addresses?
>> 
>> 
>> No, Beavis.  SMTP does not work this way.
> 
> Wrong. THere are   MTAs, that do checks AFTER the . has been sent
> and before the mail is queued.

And if someone is stupid enough to do just that in this case, they will be 
rejecting all ordinary mailing list traffic, and forwarded mail.  And that's 
why SMTP doesn't work this way.

Next time, try to provide an answer to the actual question being asked.



--=_mimegpg-commodore.email-scan.com-28713-1095807058-0010
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBULBSx9p3GYHlUOIRAolSAJ4zN03WqZXoVwGdtc2+D39uS8ERdwCfWDBS
hJYr0HcupSxhjKf2OQM5aoo=
=g1hy
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-28713-1095807058-0010--

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-28713-1095807162-0011
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Mark Marcus writes:

> On Mon, 20 Sep 2004 17:38:25 -0500, Sam <sam@email-scan.com> wrote:
> 
>>Beavis writes:
>>
>>> Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>> eiving MTA) a correspondence between the envelope addresses and
>>> the content addresses?
>>
>>No, Beavis.  SMTP does not work this way.
>>
> 
> Don't let your hatred of AC get in the way of your normally astute
> thinking.  SMTP _could_ work this way.  The protocol (as you know)
> could go
> 
> EHLO...
> MAIL FROM:...
> RCPT TO....
> DATA...
> .
> 
> At the "." the MTA could kick a 550 or 553 message: "DATA and RCPT TO
> don't match."

And what exactly do you propose to do about ordinary mailing list traffic, 
and forwarded mail, where the envelope never matches the headers?

> But, of course, more than half the mail in the world would never make
> it to the destination.   So I agree with your overall assessment, it
> is a Beavis suggestion.

So why even waste the electrons mentioning this completely hypothetical and 
clearly useless possibility?



--=_mimegpg-commodore.email-scan.com-28713-1095807162-0011
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBULC6x9p3GYHlUOIRAjqNAJ9kf9VQUqX1T9AovcQMyysot4FkKACfZ1iY
BiUx6O25gKBbyrz4EB32SQg=
=+wxs
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-28713-1095807162-0011--

Randolf Richardson wrote:
> "Alexander Skwar <from@alexander.skwar.name>" wrote in news.admin.net-
> abuse.email:
> 
> 
>>Randolf Richardson wrote:
>>
>>
>>>"dplatt@radagast.org (Dave Platt)" wrote in news.admin.net-abuse.email:
>>>
>>>
>>>>It's also technically unenforceable, unless you make a massive set of
>>>>changes to the email infrastructure.  To enforce it, you'd have to
>>>>pass along the entire set of addressees as part of every SMTP
>>>>transaction, as well as listing them in the envelope, so that the
>>>>receiving MTA could check for the presence of "blind" (unlisted)
>>>>addressees.
>>>
>>>...and that would be a huge privacy concern for obvious reasons.
>>
>>"Obvious reasons"? Why would that be? A recipient would see only
>>his name/adress. Yes, that of course makes the number of mails sent
>>out a whole lot bigger.
> 
> 
>     	Yes, obvious to those who know how SMTP is used to transport eMail 
> messages, but I'll describe it quickly for you anyway:

Obviously, that's not an obvious description :)

>     	If a user decides to send an eMail to a group of people they know, and 
> some of those people operate SMTP servers themselves, then that would 
> defeat the whole purpose of a "blind courtesy copy" since those SMTP server 
> operators could obviously have the option to find out who's in the BCC list 
> by simply looking at "the entire set of addresses" that were "passed 
> along" "as part of every SMTP transaction."

Obviously, that's wrong. Istead of trying to smartarse, you should
read up on how SMTP works.

There's no need for serverA to get the whole entire set of addresses in
the envelope. Let me explain, since you don't know SMTP: If a mail
is delivered, the sending MTA needs to send a RCPT TO to define
ONE recipient. It can send multiple RCPT TO commands in one session.
Now, "serverA" has no need to know that a mail is to be delivered
to user@serverB, as long as serverA is not a MX for serverB.

>     	Now, for a mailing list with, let's say, ~10,000 subscribers, in most 
> cases "the entire set of addresses" would consume more bandwidth than most 
> messages (assuming a typical discussions-oriented mailing list such as 
> Spam-L, BugTraq, etc.).  In these cases, the suggested approach above would 
> obviously be counter-productive in addition to the obvious privacy concerns 
> for those who prefer to just read messages without ever posting anything.

What are you talking about?

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

Randolf Richardson wrote:
> ""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
> news.admin.net-abuse.email: 
> 
> 
>>Paul Vader wrote:
> 
> [sNip]
> 
>>>Even lacking BCCs, any message sent to more than one mailserver will
>>>ALWAYS have a mismatch between the SMTP recipients and the addressees.
>>>Apparently, Beavis thinks that every mailserver gets every RCPT TO.
>>>Dumb. * 
>>
>>What are you talking about?
> 
> 
>     	Facts (and Paul Vader is absolutely right).  This is how SMTP servers 
> work.  Read the relevant RFCs for more details if you don't agree.

No, he's not talking about SMTP, facts and RfCs.

He's talking about something else: What?

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

Sam wrote:
> Mark Marcus writes:
> 
> 
>>On Mon, 20 Sep 2004 17:38:25 -0500, Sam <sam@email-scan.com> wrote:
>>
>>
>>>Beavis writes:
>>>
>>>
>>>>Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>>>eiving MTA) a correspondence between the envelope addresses and
>>>>the content addresses?
>>>
>>>No, Beavis.  SMTP does not work this way.
>>>
>>
>>Don't let your hatred of AC get in the way of your normally astute
>>thinking.  SMTP _could_ work this way.  The protocol (as you know)
>>could go
>>
>>EHLO...
>>MAIL FROM:...
>>RCPT TO....
>>DATA...
>>.
>>
>>At the "." the MTA could kick a 550 or 553 message: "DATA and RCPT TO
>>don't match."
> 
> 
> And what exactly do you propose to do about ordinary mailing list traffic, 
> and forwarded mail, where the envelope never matches the headers?

Well, the envelope should match the headers. If there's a

To: foo@serverA

the envelope should contain

RCPT TO foo@serverA

But, some of you seem to lack some knowledge in SMTP. If there's
a

To: bar@serverB

there does NOT need to be a

RCPT TO bar@serverB

> So why even waste the electrons mentioning this completely hypothetical and 
> clearly useless possibility?

How is it useless?

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

Randolf Richardson wrote:
> "Alexander Skwar <from@alexander.skwar.name>" wrote in
> news.admin.net-abuse.email: 
> 
> 
>>Randolf Richardson wrote:
> 
> [sNip]
> 
>>>without changing the 
>>>"From:," "To:," and "Cc:" SMTP headers, thus making it easy for
>>>recipients to know who the message was really addressed to.  Change the
>>>"To:" field from the eMail list's posting address to each individual
>>>recipient, and the membership will be confused.
>>
>>Why? To protect privacy, the To: would contain (in my case) JUST
>>lists@alexander.skwar.name, and nothing else (well, my Realname maybe
>>*G*). What's confusing about this?
> 
> 
>     	As a recipient of any given eMail list, I prefer to know if the 
> mailing list was addressed in "To:," "Cc:," or "BCc:" (not at all).

Yes. So? You find the mailinglist in the To: or CC:. You also
find your adress in the To: or CC:. What's confusing about
this?

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

Randolf Richardson wrote:
> "Alexander Skwar <from@alexander.skwar.name>" wrote in
> news.admin.net-abuse.email: 
> 
> 
>>Randolf Richardson wrote:
>>
>>
>>>"Alexander Skwar <from@alexander.skwar.name>" wrote in
>>>news.admin.net-abuse.email: 
> 
> [sNip]
> 
>>>>To: me@adress.is.invalid
>>>>
>>>>He wants every mail to have
>>>>
>>>>To: him@adress.is.not.invalid
>>>>
>>>>Now, to protect the privacy, this might mean, that every mail has
>>>>just one recipient, which would increase the number of mails that
>>>
>>>
>>>         Additional cost (time & money) to normal users.  This is not
>>>         good. 
>>
>>Well, yes, that's right, however, how many normal users would
>>be affected by this?
> 
> 
>     	Every user who sends eMails in this way would be affected.  

Aha. How?

> Not 
> everyone gets consistent performance from their internet connection (and 
> then there are the dial-up users who would really notice).

Why would they notice?

>     	Of course, if additional bandwidth (part of the "cost" factor) wasn't 
> an issue (in addition to the others), then spam wouldn't be an issue 
> either.

Hm?

>>No, it's not *wasted*. Everything that makes it harder for spammers
>>is a good thing -
> 
> 
>     	I agree with that.
> 
> 
>>if the bad effects on normal users are small enough to be bearable.
> 
> 
>     	This doesn't even apply here because sacrificing privacy is not what I 
> consider "small enough to be bearable."  

Me neither. But since privacy isn't sacrificed, that's still
"small enough to be bearable".

> My guess is that a lot of people 
> probably agree with me on this specific point [about protecting privacy].

Yep. However, that has nothing to do at all with what AC proposed.

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

Sam wrote:
> Alexander Skwar writes:
> 
> 
>>Sam wrote:
>>
>>>Beavis writes:
>>>
>>>
>>>
>>>>Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>>>eiving MTA) a correspondence between the envelope addresses and
>>>>the content addresses?
>>>
>>>
>>>No, Beavis.  SMTP does not work this way.
>>
>>Wrong. THere are   MTAs, that do checks AFTER the . has been sent
>>and before the mail is queued.
> 
> 
> And if someone is stupid enough to do just that in this case, they will be 
> rejecting all ordinary mailing list traffic, and forwarded mail.  And that's 
> why SMTP doesn't work this way.

Well, if there's no Bcc mechanism, then that's not true. The name is
listed in To/Cc, so how is someone "rejecting all ordinary mailing list traffic,
and forwarded mail"?

> Next time, try to provide an answer to the actual question being asked.

Same to you. It seems to me, that all of you are rejecting the
idea, because that AC guy came up with it. Seems like nobody
considers the idea.

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

In comp.os.linux.security, Alexander W. Skwar wrote:
>Well, the envelope should match the headers. If there's a
>
>To: foo@serverA
>
>the envelope should contain
>
>RCPT TO foo@serverA

What if I send an email to someone@domain1.net with a CC to
somebody@domain2.net.  The mail will be deliverd to the MX of
domain2.net with RCPT TO somebody@domain2.net while the To: header in
the DATA phase says To: someone@domain1.net.

Ergo: no match.

-- 
Maurice                                    mauricej (at) xs4all (dot) nl

Maurice Janssen wrote:
> In comp.os.linux.security, Alexander W. Skwar wrote:
> 
>>Well, the envelope should match the headers. If there's a
>>
>>To: foo@serverA
>>
>>the envelope should contain
>>
>>RCPT TO foo@serverA
> 
> 
> What if I send an email to someone@domain1.net with a CC to
> somebody@domain2.net.  The mail will be deliverd to the MX of
> domain2.net with RCPT TO somebody@domain2.net while the To: header in
> the DATA phase says To: someone@domain1.net.

Well, you will deliver two mails.

Server1:
RCPT TO: someone@domain1
To: someone@domain1
Cc: somebody@domain2

Server2:
RCPT TO: somebody@domain2
To: someone@domain1
Cc: somebody@domain2

> Ergo: no match.

Wrong.

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

"Alexander W. Skwar" <from@alexander.skwar.name> wrote in message
news:41513B37.1030203@mid.message-center.info...
> > What if I send an email to someone@domain1.net with a CC to
> > somebody@domain2.net.  The mail will be deliverd to the MX of
> > domain2.net with RCPT TO somebody@domain2.net while the To: header in
> > the DATA phase says To: someone@domain1.net.
>
> Well, you will deliver two mails.
>
> Server1:
> RCPT TO: someone@domain1
> To: someone@domain1
> Cc: somebody@domain2
>
> Server2:
> RCPT TO: somebody@domain2
> To: someone@domain1
> Cc: somebody@domain2

Unles you use a smart host in that case
SmartHost:
MAIL FROM: you@yourdomain
RCPT TO: someone@domain1
RCPT TO: somebody@domain2
DATA

The smart host has to copy and send the message to two diffrend servers.

Benno

Benno wrote:
> "Alexander W. Skwar" <from@alexander.skwar.name> wrote in message
> news:41513B37.1030203@mid.message-center.info...
> 
>>>What if I send an email to someone@domain1.net with a CC to
>>>somebody@domain2.net.  The mail will be deliverd to the MX of
>>>domain2.net with RCPT TO somebody@domain2.net while the To: header in
>>>the DATA phase says To: someone@domain1.net.
>>
>>Well, you will deliver two mails.
>>
>>Server1:
>>RCPT TO: someone@domain1
>>To: someone@domain1
>>Cc: somebody@domain2
>>
>>Server2:
>>RCPT TO: somebody@domain2
>>To: someone@domain1
>>Cc: somebody@domain2
> 
> 
> Unles you use a smart host in that case

Well, yes, that's right. However, smart hosts already do something
(like SMTP AUTH) to determine if they relay or not. In the case
of a relay, an authorized client may relay and thus for a relay
acting as a smart host, the check would make no sense.

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

In article <10ku7q68v26n1c8@news.supernews.com>,
Rex Karz  <gfy@spamblocked.com> wrote:

>All recipients are the object of the "rcpt to" command. That the Bcc:
>mechanism is abused by spammers is unfortunate.

Actually the spammers *don't* abuse the "Bcc mechanism".  They simply
generate "rcpt to" commands independently of the content of the email.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-7119-1095851631-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Alexander W. Skwar writes:

> Sam wrote:
>> Alexander Skwar writes:
>> 
>> 
>>>Sam wrote:
>>>
>>>>Beavis writes:
>>>>
>>>>
>>>>
>>>>>Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>>>>eiving MTA) a correspondence between the envelope addresses and
>>>>>the content addresses?
>>>>
>>>>
>>>>No, Beavis.  SMTP does not work this way.
>>>
>>>Wrong. THere are   MTAs, that do checks AFTER the . has been sent
>>>and before the mail is queued.
>> 
>> 
>> And if someone is stupid enough to do just that in this case, they will be 
>> rejecting all ordinary mailing list traffic, and forwarded mail.  And that's 
>> why SMTP doesn't work this way.
> 
> Well, if there's no Bcc mechanism, then that's not true.

Of course it's true.

>                                                          The name is
> listed in To/Cc,

No it's not, not for a mailing list.

>                   so how is someone "rejecting all ordinary mailing list traffic,
> and forwarded mail"?

Because messages sent to the mailing list are addressed To: 
list@example.com, and when remailed by the listserver, to the subscribers, 
verbatim, so now the message's envelope contains the recipients' addresses, 
which, of courise, is not reflected in the To: header.

This is not rocket science.  It's actually a very simple concept.

>> Next time, try to provide an answer to the actual question being asked.
> 
> Same to you. It seems to me, that all of you are rejecting the
> idea, because that AC guy came up with it.

The idea is being rejected because it's stupid.

>                                             Seems like nobody
> considers the idea.

Correct.  It's a stupid idea.


--=_mimegpg-commodore.email-scan.com-7119-1095851631-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBUV5vx9p3GYHlUOIRAuqkAJ4yDOUwRxeuHPD4xAsJoRud4kq0fQCfXRXt
Hi7TUOyt9DBPZlCzQndEdFs=
=1PTo
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-7119-1095851631-0002--

Sam wrote:
> Alexander W. Skwar writes:
> 
> 
>>Sam wrote:
>>
>>>Alexander Skwar writes:
>>>
>>>
>>>
>>>>Sam wrote:
>>>>
>>>>
>>>>>Beavis writes:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Okay. Thanks. Is there any practical way to *demand* (by the rec-
>>>>>>eiving MTA) a correspondence between the envelope addresses and
>>>>>>the content addresses?
>>>>>
>>>>>
>>>>>No, Beavis.  SMTP does not work this way.
>>>>
>>>>Wrong. THere are   MTAs, that do checks AFTER the . has been sent
>>>>and before the mail is queued.
>>>
>>>
>>>And if someone is stupid enough to do just that in this case, they will be 
>>>rejecting all ordinary mailing list traffic, and forwarded mail.  And that's 
>>>why SMTP doesn't work this way.
>>
>>Well, if there's no Bcc mechanism, then that's not true.
> 
> 
> Of course it's true.

Nope.

>>                                                         The name is
>>listed in To/Cc,
> 
> 
> No it's not, not for a mailing list.

Yes, it is. Or it would need to be.

>>                  so how is someone "rejecting all ordinary mailing list traffic,
>>and forwarded mail"?
> 
> Because messages sent to the mailing list are addressed To: 
> list@example.com, and when remailed by the listserver, to the subscribers, 
> verbatim, so now the message's envelope contains the recipients' addresses, 
> which, of courise, is not reflected in the To: header.
> 
> This is not rocket science.  It's actually a very simple concept.

You're right. And that's why the recipients adress needs to be in To/Cc. I
really wonder, why you don't get it.

This concept of course makes the number of mails sent out a lot larger.
It may also add some load to mailing list server. However, some mailing list
managers (like Mailman) can already do this. It's called full "personalization",
because it allows the ml admin to add a personalization to the body; like "Hello
Alexander!" or somesuch.

> The idea is being rejected because it's stupid.

Why?

>>                                            Seems like nobody
>>considers the idea.
> 
> Correct.  It's a stupid idea.

Okay. Why?

> 


Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

Sam <sam@email-scan.com> writes:
>> listed in To/Cc,
>
>No it's not, not for a mailing list.

To repeat - not just for mailing lists. All messages sent to more than one
mailserver will ALWAYS have a mismatch between RCPT TO and inner mail
headers. All you have to do is send a message to two people that don't have
the same mail host. *
-- 
* PV   something like badgers--something like lizards--and something
       like corkscrews.

"Alexander W. Skwar" <antworten@alexander.skwar.name> writes:
>>     	Facts (and Paul Vader is absolutely right).  This is how SMTP servers 
>> work.  Read the relevant RFCs for more details if you don't agree.
>
>No, he's not talking about SMTP, facts and RfCs.
>He's talking about something else: What?

I'm talking about SMTP. You're talking out of some stinky orifice - stop
it. *
-- 
* PV   something like badgers--something like lizards--and something
       like corkscrews.

Paul Vader wrote:
> Sam <sam@email-scan.com> writes:
> 
>>>listed in To/Cc,
>>
>>No it's not, not for a mailing list.
> 
> 
> To repeat - not just for mailing lists. All messages sent to more than one
> mailserver will ALWAYS have a mismatch between RCPT TO and inner mail
> headers. 

Yes. And as you know, that's no problem.

> All you have to do is send a message to two people that don't have
> the same mail host. *

So?

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

Chris F.A. Johnson writes:
> The evidence is in all the books I read 30 to 40 years ago on writing
> business letters; I don't have any left.

cc is defined as 'carbon copy' in my 1961 dictionary.  That's also how I
remember it.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, Wisconsin

Paul Vader wrote:
> "Alexander W. Skwar" <antworten@alexander.skwar.name> writes:
> 
>>>    	Facts (and Paul Vader is absolutely right).  This is how SMTP servers 
>>>work.  Read the relevant RFCs for more details if you don't agree.
>>
>>No, he's not talking about SMTP, facts and RfCs.
>>He's talking about something else: What?
> 
> 
> I'm talking about SMTP. 

Fine.

> You're talking out of some stinky orifice - stop
> it. *

?

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

jfh@avondale.demon.co.uk (John F Hall) writes:
>Actually the spammers *don't* abuse the "Bcc mechanism".  They simply
>generate "rcpt to" commands independently of the content of the email.

Right! Their spamware doesn't give a rat's ass what's in the inner
envelope. *
-- 
* PV   something like badgers--something like lizards--and something
       like corkscrews.

In article <415184B4.8080709@mid.message-center.info>,
Alexander W. Skwar <antworten@alexander.skwar.name> wrote:
>Sam wrote:
>> Alexander W. Skwar writes:

>>>  so how is someone "rejecting all ordinary mailing list traffic,
>>>and forwarded mail"?
>> 
>> Because messages sent to the mailing list are addressed To: 
>> list@example.com, and when remailed by the listserver, to the subscribers, 
>> verbatim, so now the message's envelope contains the recipients' addresses, 
>> which, of courise, is not reflected in the To: header.
>> 
>> This is not rocket science.  It's actually a very simple concept.
>
>You're right. And that's why the recipients adress needs to be in To/Cc. I
>really wonder, why you don't get it.

So you're saying that if someone addresses an email to jfh@a, where I
don't read it, bit have arranged for it to be forwarded to jfh@b, the
"To:" line will be changed and I'm no longer allowed to know how the
sender addressed it.

>This concept of course makes the number of mails sent out a lot larger.
>It may also add some load to mailing list server. However, some mailing
>list managers (like Mailman) can already do this. It's called full
>"personalization", because it allows the ml admin to add a
>personalization to the body; like "Hello Alexander!" or somesuch.

What a *horrible* idea.  What gives the list manager the right to alter
others' messages?

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-10265-1095893763-0004
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Alexander W. Skwar writes:

> Sam wrote:
>> 
>>>                  so how is someone "rejecting all ordinary mailing list traffic,
>>>and forwarded mail"?
>> 
>> Because messages sent to the mailing list are addressed To: 
>> list@example.com, and when remailed by the listserver, to the subscribers, 
>> verbatim, so now the message's envelope contains the recipients' addresses, 
>> which, of courise, is not reflected in the To: header.
>> 
>> This is not rocket science.  It's actually a very simple concept.
> 
> You're right. And that's why the recipients adress needs to be in To/Cc. I
> really wonder, why you don't get it.

So, instead of sending a single message to a thousand recipients @aol.com, 
you want to send a thousand messages instead.

This is an extremely stupid idea, almost reaching the Beavis-stupid level.

> This concept of course makes the number of mails sent out a lot larger.

That's an understatement of the century.

> It may also add some load to mailing list server.

Another understatement of the century.

>                                                   However, some mailing list
> managers (like Mailman) can already do this.

And that's why the mailing list vendor I use does not have this "feature" 
enabled in mailman.  Customization maybe a fine thing for Aunt Matilda's and 
Uncle Zeke's family mailing list, with ten subscribers, but it quickly stops 
being fun soon thereafter.

>                                              It's called full "personalization",
> because it allows the ml admin to add a personalization to the body; like "Hello
> Alexander!" or somesuch.
> 
>> The idea is being rejected because it's stupid.
> 
> Why?

See above.

>>>                                            Seems like nobody
>>>considers the idea.
>> 
>> Correct.  It's a stupid idea.
> 
> Okay. Why?

Because someone who actually writes E-mail software, instead of musing 
philosophically about it, says so.



--=_mimegpg-commodore.email-scan.com-10265-1095893763-0004
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBUgMDx9p3GYHlUOIRAtO5AJ9nPwphOAyx3QzeBkMXTuBcMPynIQCfR+YV
nwCi2nYFwpwNhtOClroze/s=
=cDqZ
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-10265-1095893763-0004--

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-10265-1095895405-0012
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Alexander W. Skwar writes:

> Paul Vader wrote:
> 
>> All you have to do is send a message to two people that don't have
>> the same mail host. *
> 
> So?

The gearshift to move your brain into from "Park" to "Drive", is located 
over there --------->



--=_mimegpg-commodore.email-scan.com-10265-1095895405-0012
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBUgltx9p3GYHlUOIRAtZwAJ9zBoou78Z+w43UMRGEXJ0jzilnsgCdEs48
bc3FYqeoBneZWvseO/jr1ys=
=GwjI
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-10265-1095895405-0012--

On 22 Sep 2004 22:55:48 GMT, John F Hall
<jfh@avondale.demon.co.uk> wrote:

> In article <415184B4.8080709@mid.message-center.info>,
> Alexander W. Skwar <antworten@alexander.skwar.name> wrote:
>
>>Sam wrote:
>>
>>> Alexander W. Skwar writes:
>
>>>>  so how is someone "rejecting all ordinary mailing list
>>>>traffic, and forwarded mail"?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Because messages sent to the mailing list are addressed To:
>>> list@example.com, and when remailed by the listserver, to
>>> the subscribers, verbatim, so now the message's envelope
>>> contains the recipients' addresses, which, of courise, is not
>>> reflected in the To: header.
>>>
>>> This is not rocket science.  It's actually a very simple
>>> concept.
>>
>>You're right. And that's why the recipients adress needs to be
>>in To/Cc. I really wonder, why you don't get it.
>
> So you're saying that if someone addresses an email to jfh@a,
> where I don't read it, bit have arranged for it to be forwarded
> to jfh@b, the "To:" line will be changed and I'm no longer
> allowed to know how the sender addressed it.
>
>>This concept of course makes the number of mails sent out
>>a lot larger.  It may also add some load to mailing list
>>server. However, some mailing list managers (like Mailman) can
>>already do this. It's called full "personalization", because it
>>allows the ml admin to add a personalization to the body; like
>>"Hello Alexander!" or somesuch.
>
> What a *horrible* idea.  What gives the list manager the right
> to alter others' messages?
>


Looks like a certain faction here doesn't want to discuss SPF,
but doesn't want to be honest and change the Subject: line
either.

Why is that? 
-------------

From: http://spf.pobox.com/howworks.html

In this example, AOL.com is the sending domain, and
pobox.com is the receiver.

AOL publishes an SPF record, specifying which computers on
the Internet can send mail as user@aol.com

A. When a real AOL user sends mail, pobox.com receives the
message from an AOL server.

B. Pobox checks AOL's SPF record, to make sure the server is allo
wed to send mail from AOL.

C. The server is listed, so Pobox gives the message a pass.

(Expensive content-based spam checks can be bypassed, saving reso
urces on the receiver side.)

OR

A. When a spammer forges mail from AOL, Pobox receives the
 messages from an outside server.

B. Pobox checks AOL's SPF record.

C. The server is not listed, so Pobox gives the message a
fail.

(Expensive content-based spam checks can be bypassed, saving reso
urces on the receiver side.)

Skipping ahead:

If you do get spam that passed an SPF check, then you know you
should hold the sending domain responsible for the message.

end quoted material

Not the end of spam, but a big step in the right direction.

I'm not surprised that spammers pretending to be spam fighters
don't want to talk about it, and want people to think it is
much more complex than it is.


AC


-- 
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-10265-1095898215-0014
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Beavis writes:

> Looks like a certain faction here doesn't want to discuss SPF,

Beavis, you knucklehead: last week I implemented SPF in my mail server. 
Furthermore, I hope that my modest contribution to the discussion in hand 
was helpful in the eventual defeat of Microsoft's encumbered Sender-ID 
proposal, to the benefit of SPF now being under consideration as an 
alternative replacement.

Once again you're flapping your gums without having anything intelligent to 
say on the matter.

> but doesn't want to be honest and change the Subject: line
> either.
> 
> Why is that? 
> -------------
> 
> From: http://spf.pobox.com/howworks.html

[ drivelectomy ]

Beavis, I have no doubt that you had absolutely no idea what the entire web 
page that you quoted meant to say.

> end quoted material
> 
> Not the end of spam, but a big step in the right direction.
> 
> I'm not surprised that spammers pretending to be spam fighters
> don't want to talk about it, and want people to think it is
> much more complex than it is.

http://angel.1jh.com/nanae/kooks/alanconnor.shtml


--=_mimegpg-commodore.email-scan.com-10265-1095898215-0014
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBUhRnx9p3GYHlUOIRAtaXAJ4585LhjvpD1N6Pazh3c4TAFn5RCwCfVzOd
BmY5+c06mwUsPF5EokCp1Q0=
=XSrf
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-10265-1095898215-0014--

Alan Connor <zzzzzz@xxx.yyy> writes:

[SPF]

> Not the end of spam, but a big step in the right direction.

SPF is NOT an anti-spam measure, it's an anti-forgery measure.

> I'm not surprised that spammers pretending to be spam fighters
> don't want to talk about it, and want people to think it is
> much more complex than it is.

People like the SPF web page maintainer? "SPF breaks email
forwarding." -- http://spf.pobox.com/srs.html

It's NOT as simple as just adding 'example.com. IN TXT "v=spf1
a:smtp.example.com -all"' to your DNS servers.

(followups set)
-- 
James Riden / j.riden@massey.ac.nz / Systems Security Engineer
GPG public key available at: http://www.massey.ac.nz/~jriden/
This post does not necessarily represent the views of my employer.

John F Hall wrote:
> In article <415184B4.8080709@mid.message-center.info>,
> Alexander W. Skwar <antworten@alexander.skwar.name> wrote:
> 
>>Sam wrote:
>>
>>>Alexander W. Skwar writes:
> 
> 
>>>> so how is someone "rejecting all ordinary mailing list traffic,
>>>>and forwarded mail"?
>>>
>>>Because messages sent to the mailing list are addressed To: 
>>>list@example.com, and when remailed by the listserver, to the subscribers, 
>>>verbatim, so now the message's envelope contains the recipients' addresses, 
>>>which, of courise, is not reflected in the To: header.
>>>
>>>This is not rocket science.  It's actually a very simple concept.
>>
>>You're right. And that's why the recipients adress needs to be in To/Cc. I
>>really wonder, why you don't get it.
> 
> 
> So you're saying that if someone addresses an email to jfh@a, where I
> don't read it, bit have arranged for it to be forwarded to jfh@b, the
> "To:" line will be changed and I'm no longer allowed to know how the
> sender addressed it.

Hm, another valid objection to the idea.

> What a *horrible* idea.  What gives the list manager the right to alter
> others' messages?

It's his list, his ressources.

Alexander Skwar
-- 
We'll try to cooperate fully with the IRS, because, as citizens, we feel
a strong patriotic duty not to go to jail.
		-- Dave Barry
������������������������������������������������������������������������

Sam wrote:
> Alexander W. Skwar writes:
> 
> 
>>Sam wrote:
>>
>>>>                 so how is someone "rejecting all ordinary mailing list traffic,
>>>>and forwarded mail"?
>>>
>>>Because messages sent to the mailing list are addressed To: 
>>>list@example.com, and when remailed by the listserver, to the subscribers, 
>>>verbatim, so now the message's envelope contains the recipients' addresses, 
>>>which, of courise, is not reflected in the To: header.
>>>
>>>This is not rocket science.  It's actually a very simple concept.
>>
>>You're right. And that's why the recipients adress needs to be in To/Cc. I
>>really wonder, why you don't get it.
> 
> 
> So, instead of sending a single message to a thousand recipients @aol.com, 
> you want to send a thousand messages instead.

I don't want anything at all. But what you wrote would be a consequence.

> This is an extremely stupid idea, 

Why?

>>This concept of course makes the number of mails sent out a lot larger.
> 
> That's an understatement of the century.

Okay. So?

>>>The idea is being rejected because it's stupid.
>>
>>Why?
>
> See above.

Where?

> Because someone who actually writes E-mail software, instead of musing 
> philosophically about it, says so.

You? Okay, that's a rather a reason that it must be something good.

Alexander Skwar
-- 
Tonight you will pay the wages of sin; Don't forget to leave a tip.
������������������������������������������������������������������������

Sam wrote:
> Alexander W. Skwar writes:
> 
> 
>>Paul Vader wrote:
>>
>>
>>>All you have to do is send a message to two people that don't have
>>>the same mail host. *
>>
>>So?
> 
> 
> The gearshift to move your brain into from "Park" to "Drive", is located 
> over there --------->

Okay, no doubt. You ARE an idiot and a moron.

Alexander Skwar
-- 
You speak of courage.  Obviously you do not know the difference between
courage and foolhardiness.  Always it is the brave ones who die, the soldiers.
		-- Kor, the Klingon Commander, "Errand of Mercy",
		   stardate 3201.7
������������������������������������������������������������������������

Sam <sam@email-scan.com> writes:
>This is a MIME GnuPG-signed message.  If you see this text, it means that

.... the poster doesn't much care how much garbage he spews onto Usenet.




-- 
       "The road to Paradise is through Intercourse."
        [email me at huge [at] huge [dot] org [dot] uk]

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
news.admin.net-abuse.email: 

> Paul Vader wrote:
> 
>> "Alexander W. Skwar" <antworten@alexander.skwar.name> writes:
>> 
>>>>Facts (and Paul Vader is absolutely right).  This is how SMTP servers 
>>>>work.  Read the relevant RFCs for more details if you don't agree.
>>>
>>>No, he's not talking about SMTP, facts and RfCs.
>>>He's talking about something else: What?
>> 
>> I'm talking about SMTP. 
> 
> Fine.
[sNip]

    	Now that there's agreement, does that mean you agree with Paul?

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in news.admin.net-
abuse.email:

> Randolf Richardson wrote:
> 
>> "Alexander Skwar <from@alexander.skwar.name>" wrote in
>> news.admin.net-abuse.email: 
>> 
>>>Randolf Richardson wrote:
>>> 
>>>>without changing the 
>>>>"From:," "To:," and "Cc:" SMTP headers, thus making it easy for
>>>>recipients to know who the message was really addressed to.  Change the
>>>>"To:" field from the eMail list's posting address to each individual
>>>>recipient, and the membership will be confused.
>>>
>>>Why? To protect privacy, the To: would contain (in my case) JUST
>>>lists@alexander.skwar.name, and nothing else (well, my Realname maybe
>>>*G*). What's confusing about this?
>> 
>>          As a recipient of any given eMail list, I prefer to know if the 
>> mailing list was addressed in "To:," "Cc:," or "BCc:" (not at all).
> 
> Yes. So? You find the mailinglist in the To: or CC:. You also
> find your adress in the To: or CC:. What's confusing about
> this?

    	So there's no point to modify the headers at all then, and to leave 
"To:," "Cc:," and "BCc:" SMTP headers unmodified.

    	Changing the headers adds to the confusion.  Leaving them as they are, 
including the "BCc:" header (if there even is one; YKMV), means there is no 
additional confusion -- were't you proposing changing how this works?

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
news.admin.net-abuse.email: 

> Randolf Richardson wrote:
>> "Alexander Skwar <from@alexander.skwar.name>" wrote in news.admin.net-
>> abuse.email:
>> 
>> 
>>>Randolf Richardson wrote:
>>>
>>>
>>>>"dplatt@radagast.org (Dave Platt)" wrote in
>>>>news.admin.net-abuse.email: 
[sNip]
>> Yes, obvious to those who know how SMTP is used to transport eMail 
>> messages, but I'll describe it quickly for you anyway:
> 
> Obviously, that's not an obvious description :)

    	Okay, so by implication you obviously agree that you don't know how 
SMTP is used to transport eMail messages.

[sNip]
>> Now, for a mailing list with, let's say, ~10,000 subscribers, in most 
>> cases "the entire set of addresses" would consume more bandwidth than
>> most messages (assuming a typical discussions-oriented mailing list
>> such as Spam-L, BugTraq, etc.).  In these cases, the suggested approach
>> above would obviously be counter-productive in addition to the obvious
>> privacy concerns for those who prefer to just read messages without
>> ever posting anything. 
> 
> What are you talking about?

    	I was pointing out one of the flaws with removing the "BCc:" 
functionality from SMTP.

P.S.:  I wasn't talking, I was typing.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
news.admin.net-abuse.email: 

> Randolf Richardson wrote:
> 
>> "Alexander Skwar <from@alexander.skwar.name>" wrote in
>> news.admin.net-abuse.email: 
>> 
>>>Randolf Richardson wrote:
>>>
>>>>"Alexander Skwar <from@alexander.skwar.name>" wrote in
>>>>news.admin.net-abuse.email: 
>>>> 
>>>>>To: me@adress.is.invalid
>>>>>
>>>>>He wants every mail to have
>>>>>
>>>>>To: him@adress.is.not.invalid
>>>>>
>>>>>Now, to protect the privacy, this might mean, that every mail has
>>>>>just one recipient, which would increase the number of mails that
>>>>
>>>> Additional cost (time & money) to normal users.  This is not good. 
>>>
>>>Well, yes, that's right, however, how many normal users would
>>>be affected by this?
>> 
>> Every user who sends eMails in this way would be affected.  
> 
> Aha. How?

    	Additional cost (time & money).  You already agreed with this answer, 
which hasn't changed.

>> Not everyone gets consistent performance from their internet connection
>> (and then there are the dial-up users who would really notice).
> 
> Why would they notice?

    	They would notice because:

    	    	a. Messages generally take longer to send (more BCC entries 
would obviously require more time to send).

    	    	b. Connectivity costs, especially for those who pay-by-the-byte.

>> Of course, if additional bandwidth (part of the "cost" factor) wasn't 
>> an issue (in addition to the others), then spam wouldn't be an issue 
>> either.
> 
> Hm?

    	If you can't figure this one out, then that's too bad.

[sNip]
>>>if the bad effects on normal users are small enough to be bearable.
>> 
>> This doesn't even apply here because sacrificing privacy is not what I 
>> consider "small enough to be bearable."  
> 
> Me neither. But since privacy isn't sacrificed, that's still
> "small enough to be bearable".

    	In order for Privacy not to be sacrificed, the "BCc:" SMTP headers 
must be omitted.

>> My guess is that a lot of people probably agree with me on this
>> specific point [about protecting privacy]. 
> 
> Yep. However, that has nothing to do at all with what AC proposed.

    	The "BCc:" functionality allows senders to protecting the privacy of 
their recipients.  Isn't AC advocating changes to how the "BCc:" SMTP 
header is dealt with?

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

Randolf Richardson wrote:
> ""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
> news.admin.net-abuse.email: 
> 
> 
>>Paul Vader wrote:
>>
>>
>>>"Alexander W. Skwar" <antworten@alexander.skwar.name> writes:
>>>
>>>
>>>>>Facts (and Paul Vader is absolutely right).  This is how SMTP servers 
>>>>>work.  Read the relevant RFCs for more details if you don't agree.
>>>>
>>>>No, he's not talking about SMTP, facts and RfCs.
>>>>He's talking about something else: What?
>>>
>>>I'm talking about SMTP. 
>>
>>Fine.
> 
> [sNip]
> 
>     	Now that there's agreement, does that mean you agree with Paul?

Yes, he's talking about SMTP. However, that doesn't have anything
to do with the Bcc proposal.

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

Randolf Richardson wrote:
> ""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
> news.admin.net-abuse.email: 
> 
> 
>>Randolf Richardson wrote:
>>
>>>"Alexander Skwar <from@alexander.skwar.name>" wrote in news.admin.net-
>>>abuse.email:
>>>
>>>
>>>
>>>>Randolf Richardson wrote:
>>>>
>>>>
>>>>
>>>>>"dplatt@radagast.org (Dave Platt)" wrote in
>>>>>news.admin.net-abuse.email: 
> 
> [sNip]
> 
>>>Yes, obvious to those who know how SMTP is used to transport eMail 
>>>messages, but I'll describe it quickly for you anyway:
>>
>>Obviously, that's not an obvious description :)
> 
> 
>     	Okay, so by implication you obviously agree that you don't know how 
> SMTP is used to transport eMail messages.

No. That's neither what I said nor meant.

> P.S.:  I wasn't talking, I was typing.

Thanks for the clarification. That makes of course a whole lot of
a difference.

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

Alexander Skwar wrote:
>Sam wrote:
>>Alexander W. Skwar writes:
>>>Sam wrote:
>> So, instead of sending a single message to a thousand recipients
>> @aol.com, you want to send a thousand messages instead.
> 
> I don't want anything at all. But what you wrote would be a consequence.
> (...)
>>>This concept of course makes the number of mails sent out a lot larger.
>> 
>> That's an understatement of the century.
> 
> Okay. So?

[Re-inserted]
>> It may also add some load to mailing list server.
>
> Another understatement of the century.

All right, so you don't think the extra load on the servers matters, nor
the extra bandwidth, or that the users will end up paying for this.  And
I suppose users with poor enough connection to notice the extra 20k or
so of headers in each message just ought to get themselves a better
connection.

How about actually reading and replying to the messages, then?

For openers, some user agents will take a little time to parse the 1000
recipients of a message.  That probably doesn't matter much with single
messages, but it may matter when an entire mailbox is opened.  Though I
suppose the affected people just ought to get themselves better
computers or mail readers, right?

Next, a message arrives to mailinglist with cc: to a few other people.
Someone redirect it to another mailinglist, with cc: to the first
mailinglist and those other people.  Now try to reply to that in the
second mailinglist, excluding the first mailinglist but including those
other people.  All you have got is a list of 20 recipients; no clue
which of them belong where.

For that matter, when I reply to something, I want to have some clue
about who I'm sending it to, if I ought to cc: it to somewhere else, or
if someone not on the mailinglist should be removed.  I can do that with
a few mailinglist names and individual addresses in the headers; I can
not with just a mass of individual addresses.

Next, try to unsubscribe a mailinglist with long-lived discussions.
You'll still be receiving the old discussions; you are in their To: and
cc: headers.

I don't know if you think the mailinglist name shoul be kept in the
headres after the subscribers are added: If not, new subscribers will be
left out of old discussions; if yes, a lot of people will receive
duplicate and soon dozens of each messages.  The mailinglist software
could strip duplicates, but that's a pretty fragile solution.  For
example, some sites rewrite e-mail addreses to the recipient's
"official" address or something.

-- 
Hallvard

AWS> However, some mailing list managers (like Mailman) can already do this.

S> And that's why the mailing list vendor I use does not have this
S> "feature" enabled in mailman. Customization maybe a fine thing for
S> Aunt Matilda's and Uncle Zeke's family mailing list, with ten
S> subscribers, but it quickly stops being fun soon thereafter.

"Customisation" of the message body on a per-recipient basis is largely 
irrelevant to public mailing lists where more than just one entity can 
post to the list (and indeed is just as _bad_ an idea as modifying 
Reply-To: and modifying Subject: are).  However, customisation of the 
message _envelope_ on a per-recipient basis is very useful to all sorts 
of mailing lists, as it permits the mailing list software to 
automatically detect and unsubscribe the subscriber mailbox names to 
which mail cannot be (possibly indirectly) delivered.

<URL:http://cr.yp.to/proto/verp.txt>

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in news.admin.net-
abuse.email:

> Randolf Richardson wrote:
[sNip]
>> Now that there's agreement, does that mean you agree with Paul?
> 
> Yes, he's talking about SMTP. However, that doesn't have anything
> to do with the Bcc proposal.

    	In that case, the whole "BCc proposal" is off-topic here.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

Hallvard B Furuseth wrote:
> Alexander Skwar wrote:
> 
>>Sam wrote:
>>
>>>Alexander W. Skwar writes:
>>>
>>>>Sam wrote:
>>>
>>>So, instead of sending a single message to a thousand recipients
>>>@aol.com, you want to send a thousand messages instead.
>>
>>I don't want anything at all. But what you wrote would be a consequence.
>>(...)
>>
>>>>This concept of course makes the number of mails sent out a lot larger.
>>>
>>>That's an understatement of the century.
>>
>>Okay. So?
> 
> 
> [Re-inserted]
> 
>>>It may also add some load to mailing list server.
>>
>>Another understatement of the century.
> 
> 
> All right, so you don't think the extra load on the servers matters, nor
> the extra bandwidth, or that the users will end up paying for this.

You know, it's quite interesting to find out what I think :) Especially,
when the opposite is true and just some people read my words in a way,
that allows them to make a joke.

>  And
> I suppose users with poor enough connection to notice the extra 20k or

What extra 20k? If you read the other messages, you'll find that
I proposed to send a seperate message for each and every recipient.

> How about actually reading and replying to the messages, then?

Why should I? Sam doesn't care to, so I don't care to read his
message either.

> For openers, some user agents will take a little time to parse the 1000
> recipients of a message.  That probably doesn't matter much with single
> messages, but it may matter when an entire mailbox is opened.  Though I
> suppose the affected people just ought to get themselves better
> computers or mail readers, right?

Whatever you like.

> Next, a message arrives to mailinglist with cc: to a few other people.

Which is already bad style, even with Bcc.

> Someone redirect it to another mailinglist, with cc: to the first
> mailinglist and those other people.  Now try to reply to that in the
> second mailinglist, excluding the first mailinglist but including those
> other people.  All you have got is a list of 20 recipients; no clue
> which of them belong where.

And where's the difference to the current situation?

> For that matter, when I reply to something, I want to have some clue
> about who I'm sending it to, if I ought to cc: it to somewhere else, or
> if someone not on the mailinglist should be removed.  I can do that with
> a few mailinglist names and individual addresses in the headers; I can
> not with just a mass of individual addresses.

Yep. Remember? Mailinglists send out individual messages?

> Next, try to unsubscribe a mailinglist with long-lived discussions.
> You'll still be receiving the old discussions; you are in their To: and
> cc: headers.

Well. No. You are not. If you read what I wrote, you'll see.

But simply forget about it. Or make more fun by showing that you
just want to bitch at me for me being such an idiot or whatever you're
on.
Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
news.admin.net-abuse.email: 

> Randolf Richardson wrote:
> 
>> ""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
>> news.admin.net-abuse.email: 
>> 
>>>Randolf Richardson wrote:
[sNip]
>>>>Yes, obvious to those who know how SMTP is used to transport eMail 
>>>>messages, but I'll describe it quickly for you anyway:
>>>
>>>Obviously, that's not an obvious description :)
>> 
>> Okay, so by implication you obviously agree that you don't know how 
>> SMTP is used to transport eMail messages.
> 
> No. That's neither what I said nor meant.

    	Let's review this then -- I wrote "obvious to those who know how SMTP 
is used to transport eMail messages" which implied that it wasn't obvious 
to you.  You wrote "Obviously" which implied that you agreed.  It's all 
right there, unmodified, for your digestion ... enjoy!

>> P.S.:  I wasn't talking, I was typing.
> 
> Thanks for the clarification. That makes of course a whole lot of
> a difference.

    	I'm so glad that was helpful to you.  You might want to also consider 
that the "I was typing" rule applies to every post in newsgroups that 
doesn't include an audio file attachment.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

Randolf Richardson <rr@8x.ca> wrote in news:Xns956D5EAAE83DFrr8xca@
24.64.223.211:

> "Alexander W. Skwar" 
> 
>          Let's review this then

PDNFTT

-- 
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
To the spammers, my motto: FABRICATI DIEM, PVNC.

> So, instead of sending a single message to a thousand recipients @aol.com,
> you want to send a thousand messages instead.

Those cases are basically never seen in practice.  Or at least, they're lost
in the noise.  Some mail daemons like qmail already do "this stupid thing"
just because it's simpler that way.

>> This concept of course makes the number of mails sent out a lot larger.
> That's an understatement of the century.

Actually, no.  It's an overstatement.

> Because someone who actually writes E-mail software, instead of musing
> philosophically about it, says so.

Do you have concrete measurements of real world SMTP transactions showing
that the increase in server-load, or network-use, or message-latency would
increase significantly?
The qmail people did actually do some measurements and their conclusion was
that the impact is very small.  Now, they probably did have a vested
interested in getting this result, but I still haven't seen any actually
counter-claim.


        Stefan

On Thu, 23 Sep 2004 15:43:16 GMT, Jonathan de Boyne Pollard
<J.deBoynePollard@Tesco.NET> wrote:


> OOO> OOOOOOO, OOOO OOOOOOO OOOO OOOOOOOO (OOOO OOOOOOO) OOO
> OOOOOOO OO OOOO.
>
> O> OOO OOOO'O OOO OOO OOOOOOO OOOO OOOOOO O OOO OOOO OOO OOOO
> O> OOOO "OOOOOOO" OOOOOOO OO OOOOOOO. OOOOOOOOOOOOO OOOOO
> O> O OOOO OOOOO OOO OOOO OOOOOOO'O OOO OOOOO OOOO'O OOOOOO
> O> OOOOOOO OOOO, OOOO OOO OOOOOOOOOOO, OOO OO OOOOOOO OOOOO
> O> OOOOO OOO OOOO OOOOOOOOOO.
>
> "OOOOOOOOOOOOO" OO OOO OOOOOOO OOOO OO O OOO-OOOOOOOOO OOOOO
> OO OOOOOOO OOOOOOOOOO OO OOOOOO OOOOOOO OOOOO OOOOO OOOO OOOO
> OOOO OOO OOOOOO OOO OOOO OO OOO OOOO (OOO OOOOOO OO OOOO OO
> _OOO_ OO OOOO OO OOOOOOOOO OOOOO-OO: OOO OOOOOOOOO OOOOOOO:
> OOO).  OOOOOOO, OOOOOOOOOOOOO OO OOO OOOOOOO _OOOOOOOO_ OO O
> OOO-OOOOOOOOO OOOOO OO OOOO OOOOOO OO OOO OOOOO OO OOOOOOO
> OOOOO, OO OO OOOOOOO OOO OOOOOOO OOOO OOOOOOOO OO OOOOOOOOOOOOO
> OOOOOO OOO OOOOOOOOOOO OOO OOOOOOOOOO OOOOOOO OOOOO OO OOOOO
> OOOO OOOOOO OO (OOOOOOOO OOOOOOOOOO) OOOOOOOOO.
>
><OOO:OOOO://OO.OO.OO/OOOOO/OOOO.OOO>

How typical of you to change the subject without noting the fact
on the Subject line.

Anyone who believes a word that you post is a fool. 

Here, your objective is to distract people's attention from
SPF. 

Perhaps you could explain why I can't find your alleged name
in any phonebook in Europe, America, or the Commonwealth?

The only people with your name that I could find don't even
know what the Usenet is.

SPF is a *very* good idea.

Unless you are a spammer.

http://spf.pobox.com

AC


-- 
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb

Randolf Richardson wrote:
> ""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
> news.admin.net-abuse.email: 
> 
> 
>>Randolf Richardson wrote:
>>
>>
>>>""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
>>>news.admin.net-abuse.email: 
>>>
>>>
>>>>Randolf Richardson wrote:
> 
> [sNip]
> 
>>>>>Yes, obvious to those who know how SMTP is used to transport eMail 
>>>>>messages, but I'll describe it quickly for you anyway:
>>>>
>>>>Obviously, that's not an obvious description :)
>>>
>>>Okay, so by implication you obviously agree that you don't know how 
>>>SMTP is used to transport eMail messages.
>>
>>No. That's neither what I said nor meant.
> 
>     	Let's review this then -- I wrote "obvious to those who know how SMTP 
> is used to transport eMail messages" which implied that it wasn't obvious 
> to you.  You wrote "Obviously" which implied that you agreed.  It's all 
> right there, unmodified, for your digestion ... enjoy!

Yeah, right. You're oh so clever, aren't you? Shall I give you a grade
card?

		/------------\
		|            |
		|            |
		|            |
		|     A*     |
		|            |
		|            |
		\------------/


>>>P.S.:  I wasn't talking, I was typing.
>>
>>Thanks for the clarification. That makes of course a whole lot of
>>a difference.
> 
> 
>     	I'm so glad that was helpful to you.  You might want to also consider 
> that the "I was typing" rule applies to every post in newsgroups that 
> doesn't include an audio file attachment.

Let's praise you for such a BRIGHT statement. Man, were would we be,
if everyone were so smart?

Alexander Skwar
-- 
If built in great numbers, motels will be used for nothing but illegal
purposes.
		-- J. Edgar Hoover
������������������������������������������������������������������������

The Open Sourceror's Apprentice wrote:

> PDNFTT

Ak�fi?

Alexander Skwar
-- 
At the end of your life there'll be a good rest, and no further activities
are scheduled.
������������������������������������������������������������������������

Randolf Richardson wrote:

>     	[...] off-topic here.

Yep.

Alexander Skwar
-- 
All the passions make us commit faults; love makes us commit the most
ridiculous ones.
		-- La Rochefoucauld
������������������������������������������������������������������������

Alexander W. Skwar wrote:
>> And
>> I suppose users with poor enough connection to notice the extra 20k or
> 
> What extra 20k? If you read the other messages, you'll find that
> I proposed to send a seperate message for each and every recipient.

Urque.  Maybe I should consider getting involved in only one strange
idea at a time, instead of mixing up two of them...

-- 
Hallvard

xxxx@yyy.zzz (Alan Connor) abuses:
>On Thu, 23 Sep 2004 15:43:16 GMT, Jonathan de Boyne Pollard
><J.deBoynePollard@Tesco.NET> wrote:
>
>
>> OOO> OOOOOOO, OOOO OOOOOOO OOOO OOOOOOOO (OOOO OOOOOOO) OOO
>> OOOOOOO OO OOOO.

He most certainly did NOT post that. Postediting is considered a termable
offense on many news servers. Cut it the hell out, butthead. *
-- 
* PV   something like badgers--something like lizards--and something
       like corkscrews.

In article <415252EF.40001@von.digitalprojects.com>,
Alexander Skwar  <reply-to@alexander.skwar.name> wrote:
>John F Hall wrote:

>> What a *horrible* idea.  What gives the list manager the right to alter
>> others' messages?
>
>It's his list, his ressources.

But *not* his messages.  He has the right to forward the messages or not
- though if he fails to abide by his stated policies that could be
considered an abuse.  But he doesn't have any right to *change* the
messages - they still aren't his copyright.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

"Paul Vader" wrote:
> xxxx@yyy.zzz (Alan Connor) abuses:
>
>> On Thu, 23 Sep 2004 15:43:16 GMT, Jonathan de Boyne Pollard
>> <J.deBoynePollard@Tesco.NET> wrote:
>>
>>
>>> OOO> OOOOOOO, OOOO OOOOOOO OOOO OOOOOOOO (OOOO OOOOOOO) OOO
>>> OOOOOOO OO OOOO.
>
> He most certainly did NOT post that. Postediting is considered
> a termable offense on many news servers.

There's no intelligent content there, and it is therefore not
"postediting". Mr. Connor was obviously obscuring an article
he did not wish to re-publish.

He also said:

"Here, your objective is to distract people's attention from
SPF."

Looks to me like you have the same objective as that "Morely"
fellow.

Because, of course, you _are_ that "Morely" fellow.

Steve

-- 
http://spf.pobox.com

Alan Connor <zzzzzz@xxx.yyy> wrote in 
news:IHD4d.7861$gG4.1515@newsread1.news.pas.earthlink.net:

> SPF is a *very* good idea.
> 
> Unless you are a spammer.
> 
Feel free to explain why spammers can't simply add SPF records to their 
automated scripts that sign up for hundreds of domain names at a time, and 
which already set up domain records for those domains.

SPF might, possibly, reduce joe jobs somewhat. But that's a whole different 
issue from spam. Which SPF will do *nothing* about (nor does its inventor 
claim it will).

-- 
Terry Austin
www.hyperbooks.com
Campaign Cartographer now available

Steven Conz <steve34@hotmail.com> wrote:

>"Paul Vader" wrote:
>> xxxx@yyy.zzz (Alan Connor) abuses:
>>
>>> On Thu, 23 Sep 2004 15:43:16 GMT, Jonathan de Boyne Pollard
>>> <J.deBoynePollard@Tesco.NET> wrote:
>>>
>>>
>>>> OOO> OOOOOOO, OOOO OOOOOOO OOOO OOOOOOOO (OOOO OOOOOOO) OOO
>>>> OOOOOOO OO OOOO.
>>
>> He most certainly did NOT post that. Postediting is considered
>> a termable offense on many news servers.
>
>There's no intelligent content there, and it is therefore not
>"postediting". Mr. Connor was obviously obscuring an article
>he did not wish to re-publish.
>
>He also said:
>
>"Here, your objective is to distract people's attention from
>SPF."
>
>Looks to me like you have the same objective as that "Morely"
>fellow.
>
>Because, of course, you _are_ that "Morely" fellow.
>

Ding Ding Ding, we have another kook on the loose, or just a really
stupid person.

>Steve

"Alexander Skwar <from@alexander.skwar.name>" wrote in news.admin.net-
abuse.email:

> Randolf Richardson wrote:
> 
>>          [...] off-topic here.
> 
> Yep.

    	Did you know this before I pointed it out to you?

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

"Alexander Skwar <from@alexander.skwar.name>" wrote in
news.admin.net-abuse.email: 

> Randolf Richardson wrote:
[sNip]
>> I'm so glad that was helpful to you.  You might want to also consider 
>> that the "I was typing" rule applies to every post in newsgroups that 
>> doesn't include an audio file attachment.
> 
> Let's praise you for such a BRIGHT statement. Man, were would we be,
> if everyone were so smart?

    	For starters, there wouldn't be any spammers.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

Steven Conz <steve34@hotmail.com> writes:
>Looks to me like you have the same objective as that "Morely"
>fellow.
>
>Because, of course, you _are_ that "Morely" fellow.

We are all of us Morley Dotes. *
-- 
* PV   something like badgers--something like lizards--and something
       like corkscrews.

pv+usenet@pobox.com (Paul Vader) wrote in 
news:10l6an95tnbk41f@news.supernews.com:

> Steven Conz <steve34@hotmail.com> writes:
>>Looks to me like you have the same objective as that "Morely"
>>fellow.
>>
>>Because, of course, you _are_ that "Morely" fellow.
> 
> We are all of us Morley Dotes.

Hmmm. Paging Clifto/Morely!



-- 
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
To the spammers, my motto: FABRICATI DIEM, PVNC.

On 2004-09-22, John Hasler wrote:
> Chris F.A. Johnson writes:
>> The evidence is in all the books I read 30 to 40 years ago on writing
>> business letters; I don't have any left.
>
> cc is defined as 'carbon copy' in my 1961 dictionary.  That's also how I
> remember it.

   cc is also defined as cubic centimeter and various other things; c
   is defined as copy.

   In business letters, c: meant copy, cc: meant copies.

   I don;t know when it changed generally, and there may have been
   enclaves with different usage.

-- 
    Chris F.A. Johnson                  http://cfaj.freeshell.org/shell
    ===================================================================
    My code (if any) in this post is copyright 2004, Chris F.A. Johnson
    and may be copied under the terms of the GNU General Public License

Randolf Richardson <rr@8x.ca> wrote in news:Xns956D83876FB17rr8xca@
24.64.223.211:

> "Alexander Skwar <from@alexander.skwar.name>" wrote in
> news.admin.net-abuse.email: 

[snip]

Please stop FTT.


-- 
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
To the spammers, my motto: FABRICATI DIEM, PVNC.

In news.admin.net-abuse.email - article 
<Xns956D769A533F5taustinhyperbookscom@216.168.3.50>, on Thu, 23 Sep 
2004 18:39:33 -0000, No 33 Secretary says...
> Alan Connor <zzzzzz@xxx.yyy> wrote in 
> news:IHD4d.7861$gG4.1515@newsread1.news.pas.earthlink.net:
> 
> > SPF is a *very* good idea.
> > 
> > Unless you are a spammer.
> > 
> Feel free to explain why spammers can't simply add SPF records to their 
> automated scripts that sign up for hundreds of domain names at a time, and 
> which already set up domain records for those domains.

They can but they'll have to change those scripts.  

I suspect at a point, spf MTA modules may give the option of 
rejecting SPF records representing more than a configuration defined 
number of IPs.  Currently AOL's spf record represents about 2500 IPs 
(5 24/s 2 23/s), 2.5k IP limit should cover most anyone, I'll bet AOL 
could do some tweeking and get it below 2k giving a .5k headway.  I 
wonder if even AOL really needs that much allocated.

This will invalidate a spammer's declaration of 0/8 and require their 
'bot network to be modified to keep those spf records updated.

Smaller spammers will have to do it manually and for either type of 
spammer, it adds to their "cost of goods sold", which we all know is 
a component of "the bottom line".

> SPF might, possibly, reduce joe jobs somewhat. But that's a whole different 
> issue from spam. Which SPF will do *nothing* about (nor does its inventor 
> claim it will).

SPF _will_ do something about spam, not by design but as a byproduct.

Murray Watson <JunkDTectr@adelphia.net> wrote in
news:MPG.1bbcff78cd12d43989a24@news1.news.adelphia.net: 

> In news.admin.net-abuse.email - article 
> <Xns956D769A533F5taustinhyperbookscom@216.168.3.50>, on Thu, 23 Sep 
> 2004 18:39:33 -0000, No 33 Secretary says...
>> Alan Connor <zzzzzz@xxx.yyy> wrote in 
>> news:IHD4d.7861$gG4.1515@newsread1.news.pas.earthlink.net:
>> 
>> > SPF is a *very* good idea.
>> > 
>> > Unless you are a spammer.
>> > 
>> Feel free to explain why spammers can't simply add SPF records to
>> their automated scripts that sign up for hundreds of domain names at
>> a time, and which already set up domain records for those domains.
> 
> They can but they'll have to change those scripts.  

And? Spamming has always been a cat and mouse game.
> 
> I suspect at a point, spf MTA modules may give the option of 
> rejecting SPF records representing more than a configuration defined 
> number of IPs.  Currently AOL's spf record represents about 2500 IPs 
> (5 24/s 2 23/s), 2.5k IP limit should cover most anyone, I'll bet AOL 
> could do some tweeking and get it below 2k giving a .5k headway.  I 
> wonder if even AOL really needs that much allocated.
> 
> This will invalidate a spammer's declaration of 0/8 and require their 
> 'bot network to be modified to keep those spf records updated.

You really think it would be difficult for the spammers to automatically 
configure SPF on the fly, as they transmit, to include the current part of 
the zombie network they're renting?
> 
> Smaller spammers will have to do it manually and for either type of 
> spammer, it adds to their "cost of goods sold", which we all know is 
> a component of "the bottom line".

Just creates a market for software to automate it (or, rather, expand the 
existing market).
> 
>> SPF might, possibly, reduce joe jobs somewhat. But that's a whole
>> different issue from spam. Which SPF will do *nothing* about (nor
>> does its inventor claim it will).
> 
> SPF _will_ do something about spam, not by design but as a byproduct.
> 
What? Other than cause it to be whitelisted on servers run by clueless 
admins, that is.

-- 
Terry Austin
www.hyperbooks.com
Campaign Cartographer now available

The Open Sourceror's Apprentice wrote:
> Randolf Richardson <rr@8x.ca> wrote in news:Xns956D83876FB17rr8xca@
> 24.64.223.211:
> 
> 
>>"Alexander Skwar <from@alexander.skwar.name>" wrote in
>>news.admin.net-abuse.email: 
> 
> 
> [snip]
> 
> Please stop FTT.

WTHAYTA?

Alexander Skwar
-- 
statistics, n.:
	A system for expressing your political prejudices in convincing
	scientific guise.
������������������������������������������������������������������������

Randolf Richardson wrote:

>     	Did you know this before I pointed it out to you?

That you write OT rants? Yes.

Alexander Skwar
-- 
QOTD:
	"I am not sure what this is, but an 'F' would only dignify it."
������������������������������������������������������������������������

John F Hall wrote:
> Alexander Skwar  <reply-to@alexander.skwar.name> wrote:
>>John F Hall wrote:

>>> What a *horrible* idea.  What gives the list manager the right to alter
>>> others' messages?
>>
>>It's his list, his ressources.
> 
> But *not* his messages.  He has the right to forward the messages or not
> - though if he fails to abide by his stated policies that could be
> considered an abuse.  But he doesn't have any right to *change* the
> messages - they still aren't his copyright.

"Rights" don't matter one whit here.  It's his mailing list.  He can make
whatever requirements he wants to use it.  If you don't like them, then you
have the option of not using his mailing list.  

Further, he *must* copy the messages in order to run a mailing list, and, if
his software is to obey the RFCs, he *must* alter them.  At the very least,
his server has to insert a "Received:" header.  

Hell, one could equally argue that the post office has no right to put
processing stamps on the envelopes of paper mail, since I wrote on the
envelope and it is therefore my copyright.  And they can't print barcodes
of the zip code on them either, or do *anything* which would alter the
envelope, no matter how helpful it might be to themselves or others. 
That's pretty much logically equivalent to what you're saying, with regard
to mail headers.

-- 
ZZzz   |\      _,,,---,,_     Travis S. Casey  <efindel@earthlink.net>
       /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-18254-1095978640-0001
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Beavis writes:

> Anyone who believes a word that you post is a fool. 

> SPF is a *very* good idea.
> 
> Unless you are a spammer.
> 
> http://spf.pobox.com

http://angel.1jh.com/nanae/kooks/alanconnor.shtml#Insults



--=_mimegpg-commodore.email-scan.com-18254-1095978640-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBU06Qx9p3GYHlUOIRAtQ1AJ9RIt28QnHWjcZ5cUMMZBK67M8MxgCfVQSy
BtXdd0hJkVB0E+mjwMtJjAA=
=z8bD
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-18254-1095978640-0001--

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-18254-1095979390-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Alexander Skwar writes:

> Sam wrote:
>> 
>> So, instead of sending a single message to a thousand recipients @aol.com, 
>> you want to send a thousand messages instead.
> 
> I don't want anything at all.

Yes, you do.  You just said so yourself.

>                               But what you wrote would be a consequence.

A consequence of your proposal.  Ergo, you want to do something like that.

>> This is an extremely stupid idea, 
> 
> Why?

Because.

> 
>>>This concept of course makes the number of mails sent out a lot larger.
>> 
>> That's an understatement of the century.
> 
> Okay. So?

"Comprehension For Dummies" is on sale at Barnes & Nobles around the corner.

>>>>The idea is being rejected because it's stupid.
>>>
>>>Why?
>>
>> See above.
> 
> Where?

Hig PgUp twice.

>> Because someone who actually writes E-mail software, instead of musing 
>> philosophically about it, says so.
> 
> You? Okay, that's a rather a reason that it must be something good.

Correct.  Let this be a lesson for you to never argue with your mental 
superiors, ever again.


--=_mimegpg-commodore.email-scan.com-18254-1095979390-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBU1F+x9p3GYHlUOIRAnxMAJ420rJSXLoMPaDw/LrcUBX54asDawCfWLyE
sFvaRBEwPm5wP0fCOg2xvD4=
=ydv0
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-18254-1095979390-0002--

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-18254-1095979396-0003
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Alexander Skwar writes:

> Sam wrote:
>> Alexander W. Skwar writes:
>> 
>>>Paul Vader wrote:
>>>
>>>>All you have to do is send a message to two people that don't have
>>>>the same mail host. *
>>>
>>>So?
>> 
>> The gearshift to move your brain into from "Park" to "Drive", is located 
>> over there --------->
> 
> Okay, no doubt. You ARE an idiot and a moron.

You remind me of Saddam Hussein accusing the US of violating the Geneva 
conventions.



--=_mimegpg-commodore.email-scan.com-18254-1095979396-0003
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBU1GEx9p3GYHlUOIRAobjAJ9/tFpT2bFemiyFSC2CUNzOFkGiNACeOoW/
j5C5eU5m2F66j2Rfx+CWnAA=
=FgOi
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-18254-1095979396-0003--

John Doe wrote:

> Sender ID got turned down by both the IETF and Time Warner/AOL as a way to
> solve the spam problem. The issue has apparently nothing to do with the
> technical merits of MSFT's solution, but rather, with concerns of these
> parties and the open source community that MSFT would somehow use this to
> get some sort of leverage, based on past MSFT's business practices.
> 
> Here's a take on the subject from TF:
> 
> http://gruia.blogware.com/blog/_archives/2004/9/17/142790.html
> 
> Question: is there something being developed on this front by any Linux
> vendor or third-pary open source developer?  I imagine the answer is
> "yes", but have there been any alternative proposals been made to the
> IETF?

Dude, enough.  This post has gone way too far, too long.  The IETF turned it
down because they don't like Microsoft's history as a company, not because
the solution sucks, if I remember correctly.  Leave it at that.  Who cares? 
Even if they wanted the Microsoft anti-spam, I could care less, as cell
phones, "snail" mail, pagers, and phones still work.  There are other ways
to do things.

-- 
BOFH Excuse #307: emissions from GSM-phones

"John Doe" <do_not_spam_me@nospam.org> wrote:
> Sender ID got turned down by both the IETF and Time Warner/AOL as a way to
> solve the spam problem. The issue has apparently nothing to do with the
> technical merits of MSFT's solution, but rather, with concerns of these
> parties and the open source community that MSFT would somehow use this to
> get some sort of leverage, based on past MSFT's business practices.
>
> Here's a take on the subject from TF:
>
> http://gruia.blogware.com/blog/_archives/2004/9/17/142790.html
>
> Question: is there something being developed on this front by any Linux
> vendor or third-pary open source developer?  I imagine the answer is "yes",
> but have there been any alternative proposals been made to the IETF?

The _fundamental_ problem is that Microsoft has put in a patent
application surrounding some parts of the Sender ID mechanism.

   "There is at least rough consensus that the participants of the
   working group cannot accurately describe the specific claims of the
   patent application. This stems from the fact that the patent
   application is not publicly available. Given this, it is the
   opinion of the co-chairs that MARID should not undertake work on
   alternate algorithms reasonably thought to be covered by the patent
   application."

There is no confidence available that an alternative mechanism that
works in any vaguely similar fashion would not run afoul of
Microsoft's patent application.

The problem, in essence, is that while people could come up with
clever ideas, there is no way to guarantee that it would not infringe
on Microsoft's patent application, and if it did, this would cause
grave problems.

In effect, trying to build something similar to Sender ID is like
walking blindfolded through a minefield.  Chances are high that you'll
unknowingly blow limbs off.
-- 
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','ntlug.org').
http://www.ntlug.org/~cbbrowne/
You know  how most packages say  "Open here". What is  the protocol if
the package says, "Open somewhere else"?

"Alexander Skwar <from@alexander.skwar.name>" wrote in news.admin.net-
abuse.email:

> Randolf Richardson wrote:
> 
>>          Did you know this before I pointed it out to you?
> 
> That you write OT rants? Yes.

    	You didn't answer my question.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

T> I'm sure greater and wiser minds than mine have already
T> debated SPF, so is there a "why SPF won't work" website?

r> No,

You mean yes.  It even comes up, albeit in amongst pages about
sunscreen, when one puts those very four items into Google's Web search.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-spf-is-harmful.html>

r> but they're probably should at least be a FAQ.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/fga-not-faq.html>

r> None of this surprises experienced observers:

Several of us predicted it.  And there are further consequences ahead.

r> it was obvious that spammers would be the first to adopt, and to
r> game, SPF.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-anti-ubm-dont-work.html>

Sam wrote:
> Alexander Skwar writes:
> 
> 
>>Sam wrote:
>>
>>>So, instead of sending a single message to a thousand recipients @aol.com, 
>>>you want to send a thousand messages instead.
>>
>>I don't want anything at all.
> 
> Yes, you do.  You just said so yourself.

No, I said nothing. If at all, I wrote something.

>>                              But what you wrote would be a consequence.
> 
> A consequence of your proposal.  Ergo, you want to do something like that.

You don't tell me, what I want.

>>>This is an extremely stupid idea, 
>>
>>Why?
> 
> Because.

Ah, alright. Thanks for helping me understand.

But, why did you say it is a stupid idea?

>>>>This concept of course makes the number of mails sent out a lot larger.
>>>
>>>That's an understatement of the century.
>>
>>Okay. So?
> 
> "Comprehension For Dummies" is on sale at Barnes & Nobles around the corner.

See, I would not have known. When you're through with your copy, do you
think I can borrow it?

>>>>>The idea is being rejected because it's stupid.
>>>>
>>>>Why?
>>>
>>>See above.
>>
>>Where?
> 
> Hig PgUp twice.

Hig?

>>>Because someone who actually writes E-mail software, instead of musing 
>>>philosophically about it, says so.
>>
>>You? Okay, that's a rather a reason that it must be something good.
> 
> Correct.  Let this be a lesson for you to never argue with your mental 
> superiors, ever again.

Okay. That means, I can argue with you again, can't I? You aren't mixing
up "superior" and "inferior", are you?

Alexander Skwar
-- 
BOFH Excuse #25:

Decreasing electron flux
������������������������������������������������������������������������

Sam wrote:

> You remind me of Saddam Hussein accusing the US of violating the Geneva 
> conventions.

Well, he was right. Or do you think that the attack of the US was justified
by anything other than the interest in oil of Baby Bush and his gang?

But what does this have to do with you acting like a total idiot?

Alexander Skwar
-- 
Disclaimer: "These opinions are my own, though for a small fee they be
yours too."
		-- Dave Haynie
������������������������������������������������������������������������

Randolf Richardson wrote:
> "Alexander Skwar <from@alexander.skwar.name>" wrote in news.admin.net-
> abuse.email:

Nope. I wrote in colm. Fix your attribution line, please. It should
either contain the correct newsgroup name or, since that's not possible,
all newsgroup names or, since that's *WAY* too long, no newsgroup
name at all.

>>Randolf Richardson wrote:
>>
>>>         Did you know this before I pointed it out to you?
>>
>>That you write OT rants? Yes.
> 
>     	You didn't answer my question.

That's right.

Alexander Skwar
-- 
Sho' they got to have it against the law.  Shoot, ever'body git high,
they wouldn't be nobody git up and feed the chickens.  Hee-hee.
		-- Terry Southern
������������������������������������������������������������������������

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-814-1096024629-0003
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Alexander Skwar writes:

> Sam wrote:
> 
>> You remind me of Saddam Hussein accusing the US of violating the Geneva 
>> conventions.
> 
> Well, he was right.

Oh, look, another Saddam Hussein sympathetiser.  And a looney maroon, to 
boot.  Who would've thunk it?

>                     Or do you think that the attack of the US was justified
> by anything other than the interest in oil of Baby Bush and his gang?

Yes, it was justified.

> But what does this have to do with you acting like a total idiot?

It shows your mental, and intellectual, bankruptcy.


--=_mimegpg-commodore.email-scan.com-814-1096024629-0003
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBVAI1x9p3GYHlUOIRAlhZAJwLWmf8L0YlfNuKO5L3+/ioiaYPnwCeNlM1
sCg1ZZYCC5Nhy85y803PI6E=
=zMNt
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-814-1096024629-0003--

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-814-1096024631-0004
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Alexander Skwar writes:

> Sam wrote:
>> Alexander Skwar writes:
>> 
>> 
>>>Sam wrote:
>>>
>>>>So, instead of sending a single message to a thousand recipients @aol.com, 
>>>>you want to send a thousand messages instead.
>>>
>>>I don't want anything at all.
>> 
>> Yes, you do.  You just said so yourself.
> 
> No, I said nothing.

Right.  Nothing substantive.

>                     If at all, I wrote something.

You wrote nothing.

> 
>>>                              But what you wrote would be a consequence.
>> 
>> A consequence of your proposal.  Ergo, you want to do something like that.
> 
> You don't tell me, what I want.

Somebody has to.  You don't know yourself, what you want.

>>>>This is an extremely stupid idea, 
>>>
>>>Why?
>> 
>> Because.
> 
> Ah, alright. Thanks for helping me understand.

Anytime.

> But, why did you say it is a stupid idea?

Because it's true.

>>>>>This concept of course makes the number of mails sent out a lot larger.
>>>>
>>>>That's an understatement of the century.
>>>
>>>Okay. So?
>> 
>> "Comprehension For Dummies" is on sale at Barnes & Nobles around the corner.
> 
> See, I would not have known.

That, amongst many other things.


>>>>>>The idea is being rejected because it's stupid.
>>>>>
>>>>>Why?
>>>>
>>>>See above.
>>>
>>>Where?
>> 
>> Hig PgUp twice.
> 
> Hig?

As I told you, the gearshift to move your brain from "Neutral" to "Drive" is 
over there -------->

>>>>Because someone who actually writes E-mail software, instead of musing 
>>>>philosophically about it, says so.
>>>
>>>You? Okay, that's a rather a reason that it must be something good.
>> 
>> Correct.  Let this be a lesson for you to never argue with your mental 
>> superiors, ever again.
> 
> Okay. That means, I can argue with you again, can't I?

No, you can't.  That's the point.

>                                                        You aren't mixing
> up "superior" and "inferior", are you?

No I'm not.


--=_mimegpg-commodore.email-scan.com-814-1096024631-0004
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBVAI3x9p3GYHlUOIRAuqWAJ45szHA97ejefzMBaAdLd7lDVxL0gCcC4gX
n666mKPdIeBM7SlxneOqOk8=
=jDof
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-814-1096024631-0004--

SC> He also said:
SC>
SC> "Here, your objective is to distract people's attention from SPF."

.... when, of course, it is readily apparent from reading the actual post 
that my objective was to continue the discussion at hand about mailing 
lists and header munging.  Alan's objective, conversely, was no doubt to 
derail that discussion, because it had utterly demolished his daft idea 
about headers and envelopes being required to match and the elimination 
of the Blind Carbon Copy mechanism.  (People who have been paying 
attention over the past year or so will realise that Alan wants to 
legitimise these foolish notions because then that will justify the 
broken behaviour of the UBM-sending mail software that he purveys, which 
throws away mail that uses blind carbon copying.)  Hence the change of 
subject, the non sequitur, the (vain) attempts to goad, and (as a backup 
strategy) the sock puppet - all to get people talking about something 
else other than the sheer stupidity of his idea, given the way that 
mailing lists and other things actually work.

S> Ding Ding Ding, we have another kook on the loose, or just a really
S> stupid person.

No, it's not another kook.  It's the same kook.  It's almost certainly 
merely another one-time sock puppet of Alan's, popping up and taking his 
side.  He has produced one every few months, in various fora (from 
survivalism to Buddhism, Google Groups reveals), to bolster his "The 
lurkers agree with me in e-mail." claims.  Notice the same writing 
style, the same NNTP server (He's found a German one that provides him 
with more anonymity, which his other long-term aliases in other 
newsgroups have been using for a few months now.), and the same attacks 
on the b�te du jour (which is Morley at the moment).

<URL:http://angel.1jh.com./nanae/kooks/alanconnor.shtml#SockPuppets>

Of course, you will also notice Alan once again exhibiting his 
"Killfiled for 90 seconds" policy of killfiling me on 2004-09-13 and 
then ten days later on 2004-09-23 reading one of my posts and replying 
to it.

<URL:http://angel.1jh.com./nanae/kooks/alanconnor.shtml#KillfiledFor>
<URL:news:///DZl1d.240$ax4.213@newsread3.news.pas.earthlink.net>
<URL:news:///IHD4d.7861$gG4.1515@newsread1.news.pas.earthlink.net>

On Fri, 24 Sep 2004 15:43:04 GMT, Jonathan de Boyne Pollard
<J.deBoynePollard@Tesco.NET> wrote:


> SC> He also said:
> SC>
> SC> "Here, your objective is to distract people's attention
> SC> from SPF."

My initials are "AC" *moron*.

>
> ... when, of course, it is readily apparent from reading the
> actual post that my objective was to continue the discussion at
> hand about mailing lists and header munging.  Alan's objective,
> conversely, was no doubt to derail that discussion, because
> it had utterly demolished his daft idea about headers and
> envelopes being required to match and the elimination of the
> Blind Carbon Copy mechanism. 

Yes. A spammer would definitely not like those ideas.

There. I've read enough of your garbage for one day.

Say whatever you want, you *petty criminal*, but you can't get
your trash in my mailbox.

You may now kiss my ass and shut your lying mouth.

<snip>

AC

-- 
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb

xxxx@yyy.zzz (global village idiot Alan Connor) writes:
>There. I've read enough of your garbage for one day.
>
>Say whatever you want, you *petty criminal*, but you can't get
>your trash in my mailbox.

What are you, 12? Take your ball and go home. *
-- 
* PV   something like badgers--something like lizards--and something
       like corkscrews.

Alexander Skwar <from@alexander.skwar.name> wrote in news:4153A231.8090909
@von.digitalprojects.com:

> Nope. I wrote in colm. Fix your attribution line, please. It should
> either contain the correct newsgroup name or, since that's not possible,
> all newsgroup names or, since that's *WAY* too long, no newsgroup
> name at all.

Now I remember why I don't read colm.

*PLONK*

-- 
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
To the spammers, my motto: FABRICATI DIEM, PVNC.

In article <kihvic.5uf.ln@lostthoughts.org>,
Travis Casey  <efindel@earthlink.net> wrote:
>John F Hall wrote:

>> But *not* his messages.  He has the right to forward the messages or not
>> - though if he fails to abide by his stated policies that could be
>> considered an abuse.  But he doesn't have any right to *change* the
>> messages - they still aren't his copyright.
>
>"Rights" don't matter one whit here.  It's his mailing list.  He can make
>whatever requirements he wants to use it.

No, he still - as for any action - has to behave lawfully.

>Further, he *must* copy the messages in order to run a mailing list, and, if
>his software is to obey the RFCs, he *must* alter them.  At the very least,
>his server has to insert a "Received:" header.  

But not to alter the *message*.

>Hell, one could equally argue that the post office has no right to put
>processing stamps on the envelopes of paper mail, since I wrote on the
>envelope and it is therefore my copyright.

You could argue that if you were feeling particularly stupid.

>And they can't print barcodes of the zip code on them either, or do
>*anything* which would alter the envelope, no matter how helpful it
>might be to themselves or others.  That's pretty much logically
>equivalent to what you're saying, with regard to mail headers.

I have said nothing about mail headers (in this context).  I said that
changing the *messages* by "personalising" them - by adding phrases like
"Hello Alexander" to them - was a horrible idea, falls foul of the
writers' copyrights (and exceeds any implied licence given to enable the
emails to be processed).

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

jfh@avondale.demon.co.uk (John F Hall) wrote in news:cj1uis$32s$1
@avondale.demon.co.uk:

> I have said nothing about mail headers (in this context).  I said that
> changing the *messages* by "personalising" them - by adding phrases like
> "Hello Alexander" to them - was a horrible idea, falls foul of the
> writers' copyrights (and exceeds any implied licence given to enable the
> emails to be processed).

The headers are part and parcel of the message.  If you separate the 
headers of the message from the body of the message, neither one is of any 
use whatsoever.

If you wish to refer to changes to the *body of the message*, well and 
good; but the message contains a body *and* headers, else it is not 
possible to even attempt delivery.

Furthermore, your "legal" arguments have no force that you can bring to 
bear outside the jursidiction of the UK, and I am sure you are aware of 
that salient fact.  The Berne Convention covers *published* works and works 
written *for publication* and does not apply to private correspondence, as 
regards altering content.

-- 
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
To the spammers, my motto: FABRICATI DIEM, PVNC.

In news.admin.net-abuse.email - article 
<Xns956D8D6C6E7B5taustinhyperbookscom@216.168.3.50>, on Thu, 23 Sep 
2004 20:54:09 -0000, No 33 Secretary says...
> Murray Watson <JunkDTectr@adelphia.net> wrote in
> news:MPG.1bbcff78cd12d43989a24@news1.news.adelphia.net: 
> 
> > In news.admin.net-abuse.email - article 
> > <Xns956D769A533F5taustinhyperbookscom@216.168.3.50>, on Thu, 23 Sep 
> > 2004 18:39:33 -0000, No 33 Secretary says...
> >> Alan Connor <zzzzzz@xxx.yyy> wrote in 
> >> news:IHD4d.7861$gG4.1515@newsread1.news.pas.earthlink.net:
> >> 
> >> > SPF is a *very* good idea.
> >> > 
> >> > Unless you are a spammer.
> >> > 
> >> Feel free to explain why spammers can't simply add SPF records to
> >> their automated scripts that sign up for hundreds of domain names at
> >> a time, and which already set up domain records for those domains.
> > 
> > They can but they'll have to change those scripts.  
> 
> And? Spamming has always been a cat and mouse game.

Correct.  The mouse now has to run a little further and harder to get 
to the mouse hole in the wall.  There's a little more cost to 
acquiring that cheese.  After you do that enough, the mouse says, 
it's not worth the effort unless it's a big chunk of cheese.

> > I suspect at a point, spf MTA modules may give the option of 
> > rejecting SPF records representing more than a configuration defined 
> > number of IPs.  Currently AOL's spf record represents about 2500 IPs 
> > (5 24/s 2 23/s), 2.5k IP limit should cover most anyone, I'll bet AOL 
> > could do some tweeking and get it below 2k giving a .5k headway.  I 
> > wonder if even AOL really needs that much allocated.
> > 
> > This will invalidate a spammer's declaration of 0/8 and require their 
> > 'bot network to be modified to keep those spf records updated.
> 
> You really think it would be difficult for the spammers to automatically 
> configure SPF on the fly, as they transmit, to include the current part of 
> the zombie network they're renting?

No, not at all but if a spammer can't build it with his own man-
hours, he'll have to buy it so, as I state in the next sentence, it 
adds to their cost of goods sold.

> > Smaller spammers will have to do it manually and for either type of 
> > spammer, it adds to their "cost of goods sold", which we all know is 
> > a component of "the bottom line".
> 
> Just creates a market for software to automate it (or, rather, expand the 
> existing market).

Correct, raising the cost of goods sold.  In case you haven't made 
the correlation, when the cost of goods sold goes up and you don't 
have a corresponding increase in the sales price, your per unit 
revenue goes down.  Ie., year end bonuses get smaller.

> >> SPF might, possibly, reduce joe jobs somewhat. But that's a whole
> >> different issue from spam. Which SPF will do *nothing* about (nor
> >> does its inventor claim it will).
> > 
> > SPF _will_ do something about spam, not by design but as a byproduct.
> > 
> What? Other than cause it to be whitelisted on servers run by clueless 
> admins, that is.

On my boxes it will stop the spam that is forged.  Don't give them 
too much credit.  Spammers still try to use hosts listed by the top 
*bl lists.  They're playing the numbers.  What it boils down to is 
similar to the premise security system phenomenon.  If a burglar sees 
a security system sign in front of a house, unless they're after 
something really special to them, they'll go to the next neighbor and 
the first guy on the street that doesn't have a sign is the one that 
gets burgled.

If you don't want to implement it, don't.  If you don't want to have 
_any_ influence over what hosts are sending mail using your domain, 
don't publish a record.  If you don't mind getting spam from 
62.212.118.161, addressed from: @yahoo.com , don't implement it on 
your server.  If you don't mind receiving Mydoom viruses from 
65.4.76.34 claiming to be from aol.com, don't implement it on your 
server.

Murray Watson <JunkDTectr@adelphia.net> wrote in
news:MPG.1bbe551c75a3b3c8989a2a@news1.news.adelphia.net: 

> In news.admin.net-abuse.email - article 
> <Xns956D8D6C6E7B5taustinhyperbookscom@216.168.3.50>, on Thu, 23 Sep 
> 2004 20:54:09 -0000, No 33 Secretary says...
>> Murray Watson <JunkDTectr@adelphia.net> wrote in
>> news:MPG.1bbcff78cd12d43989a24@news1.news.adelphia.net: 
>> 
>> > In news.admin.net-abuse.email - article 
>> > <Xns956D769A533F5taustinhyperbookscom@216.168.3.50>, on Thu, 23 Sep
>> > 2004 18:39:33 -0000, No 33 Secretary says...
>> >> Alan Connor <zzzzzz@xxx.yyy> wrote in 
>> >> news:IHD4d.7861$gG4.1515@newsread1.news.pas.earthlink.net:
>> >> 
>> >> > SPF is a *very* good idea.
>> >> > 
>> >> > Unless you are a spammer.
>> >> > 
>> >> Feel free to explain why spammers can't simply add SPF records to
>> >> their automated scripts that sign up for hundreds of domain names
>> >> at a time, and which already set up domain records for those
>> >> domains. 
>> > 
>> > They can but they'll have to change those scripts.  
>> 
>> And? Spamming has always been a cat and mouse game.
> 
> Correct.  The mouse now has to run a little further and harder to get 
> to the mouse hole in the wall.  There's a little more cost to 
> acquiring that cheese.  After you do that enough, the mouse says, 
> it's not worth the effort unless it's a big chunk of cheese.

Yeah, all the big time spammers have stopped because it's gotten so 
difficult. That's some mighty fine dope you're smoking.
> 
>> > I suspect at a point, spf MTA modules may give the option of 
>> > rejecting SPF records representing more than a configuration
>> > defined number of IPs.  Currently AOL's spf record represents about
>> > 2500 IPs (5 24/s 2 23/s), 2.5k IP limit should cover most anyone,
>> > I'll bet AOL could do some tweeking and get it below 2k giving a
>> > .5k headway.  I wonder if even AOL really needs that much
>> > allocated. 
>> > 
>> > This will invalidate a spammer's declaration of 0/8 and require
>> > their 'bot network to be modified to keep those spf records
>> > updated. 
>> 
>> You really think it would be difficult for the spammers to
>> automatically configure SPF on the fly, as they transmit, to include
>> the current part of the zombie network they're renting?
> 
> No, not at all but if a spammer can't build it with his own man-
> hours, he'll have to buy it so, as I state in the next sentence, it 
> adds to their cost of goods sold.

It has in the past, to little, if any effect. Spam continues to grow and 
grow.
> 
>> > Smaller spammers will have to do it manually and for either type of
>> > spammer, it adds to their "cost of goods sold", which we all know
>> > is a component of "the bottom line".
>> 
>> Just creates a market for software to automate it (or, rather, expand
>> the existing market).
> 
> Correct, raising the cost of goods sold.

Not really, given how trivial a change it would be to existing packages 
(which are already setting up DNS settings for the domain in the first 
place. This adds, literally, a single line of code.)

>  In case you haven't made 
> the correlation, when the cost of goods sold goes up and you don't 
> have a corresponding increase in the sales price, your per unit 
> revenue goes down.  Ie., year end bonuses get smaller.

If any spammers of any significance had gone out of business due to 
increased operating costs, in the last, oh, three years, I wouldn't be 
laughing at your right now.
> 
>> >> SPF might, possibly, reduce joe jobs somewhat. But that's a whole
>> >> different issue from spam. Which SPF will do *nothing* about (nor
>> >> does its inventor claim it will).
>> > 
>> > SPF _will_ do something about spam, not by design but as a
>> > byproduct. 
>> > 
>> What? Other than cause it to be whitelisted on servers run by
>> clueless admins, that is.
> 
> On my boxes it will stop the spam that is forged.

No. It will not stop it. It will convert it to spam from temporary domains. 
You're smoking dope if you think it will stop it.

>  Don't give them 
> too much credit.

Why not? Spam has continued to grow and grow and grow, every year, at ever 
increasing rates.

>  Spammers still try to use hosts listed by the top 
> *bl lists.  They're playing the numbers.  What it boils down to is 
> similar to the premise security system phenomenon.  If a burglar sees 
> a security system sign in front of a house, unless they're after 
> something really special to them, they'll go to the next neighbor and 
> the first guy on the street that doesn't have a sign is the one that 
> gets burgled.

If that's the case, then why do you need to adapt to new spamming 
techniques? I mean, really, you just claimed that any effective means you 
used in the past would scare them off in the future. In other words, good 
dope.
> 
> If you don't want to implement it, don't.

Forgeries don't bother me, especially on incoming messages. I have more 
effective methods, which is to say, methods that will actually block spam.

>  If you don't want to have 
> _any_ influence over what hosts are sending mail using your domain, 
> don't publish a record.

At this point, publishing an SPF record seems unlikely to have any effect 
anyway.

>  If you don't mind getting spam from 
> 62.212.118.161, addressed from: @yahoo.com , don't implement it on 
> your server.  If you don't mind receiving Mydoom viruses from 
> 65.4.76.34 claiming to be from aol.com, don't implement it on your 
> server.
> 
And if you don't want to be laughed at, don't claim that SPF will stop a 
single piece of spam, cuz it won't, and don't claim that trivial increases 
in cost will drive spammers out of business, cuz they never have in the 
past.

-- 
Terry Austin
www.hyperbooks.com
Campaign Cartographer now available

No 33 Secretary <taustin+usenet@hyperbooks.com> writes:
|
| At this point, publishing an SPF record seems unlikely to have any effect 
| anyway.
| 
| ...don't claim that SPF will stop a 
| single piece of spam, cuz it won't, and don't claim that trivial increases 
| in cost will drive spammers out of business, cuz they never have in the 
| past.

Preventing a crime is a team effort in society. Laws are written but
they won't help if nobody is obeying them. And police force alone cannot
prevent or stop crime.

So, people would like to live in better and safe place. The form
neighbor watches. Voluntary groups to patrol in their free time. And
that works, otherwise people wouldn't do it.

If you believe neighbor watches is waste of time, we other have seen
how SPF really works. Please ask someone to show you mail server's
logs and rejections based on SPF checks. And they are increasing,
increasing ... the more people use it.

So, join and take actions you too.

Jari

In article <Xns956E8A9C1B987MorelyDotesspamblock@216.99.211.247>,
The Open Sourceror's Apprentice <spam@uce.gov> wrote:
>jfh@avondale.demon.co.uk (John F Hall) wrote in news:cj1uis$32s$1
>@avondale.demon.co.uk:
>
>> I have said nothing about mail headers (in this context).  I said that
>> changing the *messages* by "personalising" them - by adding phrases like
>> "Hello Alexander" to them - was a horrible idea, falls foul of the
>> writers' copyrights (and exceeds any implied licence given to enable the
>> emails to be processed).
>
>The headers are part and parcel of the message.  If you separate the 
>headers of the message from the body of the message, neither one is of any 
>use whatsoever.
>
>If you wish to refer to changes to the *body of the message*, well and 
>good; but the message contains a body *and* headers, else it is not 
>possible to even attempt delivery.

I'm referring to what the writer *writes*.  Headers are added by
software, processed by software, and modified by software - all in
accordance with the relevant RFCs, and all with the object of
transferring the *message*, as written, to the intended recipient.

There is, I hope, no doubt that modifying the actual message is
different in kind from modifying headers or modifying the protocol
commands - anyone who says otherwise is being rather disingenuous.

But it's all rather specious anyhow, the context showed what I was
talking about - simply a comment on what someone else had said.

>Furthermore, your "legal" arguments have no force that you can bring to 
>bear outside the jursidiction of the UK, and I am sure you are aware of 
>that salient fact.  The Berne Convention covers *published* works and works 
>written *for publication* and does not apply to private correspondence, as 
>regards altering content.

The UK and many other countries.

I don't have the Berne definition to hand - and frankly this isn't
important enough to make me find it - but as far as the UK is concerned
(and those countries that followed its lead) copyright exists as soon as
a "literary work" (i.e. anything that is written) is "recorded, in
writing or otherwise".  It does not have to be published, though
publication does have effects.

My understanding of "private correspondence" is that the recipient gains
title to the *document* and may do what they like with it, but does not
gain title to its *copyright* so may not publish copies nor misrepresent
the content.

Are you saying that even in those places where copyright isn't involved
(if any) that changing the content *isn't* a "horrible idea"?

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

In news.admin.net-abuse.email - article 
<Xns956E98BB0EA13taustinhyperbookscom@216.168.3.50>, on Fri, 24 Sep 
2004 22:00:50 -0000, No 33 Secretary says...
> > Correct.  The mouse now has to run a little further and harder to get 
> > to the mouse hole in the wall.  There's a little more cost to 
> > acquiring that cheese.  After you do that enough, the mouse says, 
> > it's not worth the effort unless it's a big chunk of cheese.
> 
> Yeah, all the big time spammers have stopped because it's gotten so 
> difficult. That's some mighty fine dope you're smoking.

I know of about 100k CFO's that would say the same thing about your 
cavilier attitude about the effect of increased costs on the bottom 
line.

Hey, you're right.  Spammers are so brilliant, they are all technical 
and financial wizzards and have us beat.

I give in.



..... I thought I recognized that name, back in you go.

Meanwhile, as our hero sinks slowly in the West, on 24 Sep 2004, 
jfh@avondale.demon.co.uk (John F Hall) wrote in news:cj2ekk$7nd$1
@avondale.demon.co.uk:

> Are you saying that even in those places where copyright isn't involved
> (if any) that changing the content *isn't* a "horrible idea"?

Changing content *with the proviso that malicious content MUST be changed 
or removed* is always a bad idea.

Phishing spams and various sorts of malware are the exception; and the 
phishers can be defeated by a router redirect, so I'm not really adamanet 
about that content.

-- 
Solid Web hosting, responsive support, effective spam-blocking.
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Brad Jesness FAQ: http://www.wilhelp.com/bj_faq/

In article <Xns956F60C909979morelydotespcgamerev@192.168.0.197>,
Morely 'I drank what?' Dotes <morelydotes@spamblocked.com> wrote:
>Meanwhile, as our hero sinks slowly in the West, on 24 Sep 2004, 
>jfh@avondale.demon.co.uk (John F Hall) wrote in news:cj2ekk$7nd$1
>@avondale.demon.co.uk:
>
>> Are you saying that even in those places where copyright isn't involved
>> (if any) that changing the content *isn't* a "horrible idea"?
>
>Changing content *with the proviso that malicious content MUST be changed 
>or removed* is always a bad idea.
>
>Phishing spams and various sorts of malware are the exception; and the 
>phishers can be defeated by a router redirect, so I'm not really adamanet 
>about that content.

My inclination is to say that emails can be accepted or rejected, but
that if accepted their content shouldn't be changed.

I see a possible grey area with viruses.  I think I would say drop but
it depends on the relative volumes of "pure" viruses containing only a
trojan or whatever, and viruses that have attached themselves to ordinary
email, and on whether the difference can be identified.  I suspect that
the former are now the overwhelming majority, so a simple "drop" is the
right action.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

Murray Watson <JunkDTectr@adelphia.net> wrote in 
news:MPG.1bbe9ffb627b1519989a2e@news1.news.adelphia.net:

> In news.admin.net-abuse.email - article 
> <Xns956E98BB0EA13taustinhyperbookscom@216.168.3.50>, on Fri, 24 Sep 
> 2004 22:00:50 -0000, No 33 Secretary says...
>> > Correct.  The mouse now has to run a little further and harder to get 
>> > to the mouse hole in the wall.  There's a little more cost to 
>> > acquiring that cheese.  After you do that enough, the mouse says, 
>> > it's not worth the effort unless it's a big chunk of cheese.
>> 
>> Yeah, all the big time spammers have stopped because it's gotten so 
>> difficult. That's some mighty fine dope you're smoking.
> 
> I know of about 100k CFO's that would say the same thing about your 
> cavilier attitude about the effect of increased costs on the bottom 
> line.

Irrelevant to the issue at hand, which is that the guy who thought up SPF 
says it won't stop spam.
> 
> Hey, you're right.  Spammers are so brilliant, they are all technical 
> and financial wizzards and have us beat.
> 
> I give in.

Good. STUF.
> 
> 
> 
> .... I thought I recognized that name, back in you go.
> 
Good riddance.

-- 
Terry Austin
http://www.hyperbooks.com/
Campaign Cartographer Now Available

Meanwhile, as our hero sinks slowly in the West, on 25 Sep 2004, 
jfh@avondale.demon.co.uk (John F Hall) wrote in news:cj4gq7$kuv$1
@avondale.demon.co.uk:

> My inclination is to say that emails can be accepted or rejected, but
> that if accepted their content shouldn't be changed.

In general, I agree with that - when we're discussing the mesasage body, of 
course.

Adding an advertising .sig to email provied by a free site is not horrific, 
either, within reason (and for a quick example, an HTML .sig containing an 
image, even if it's ntyo a web bug, is *NOT* within reason).

> I see a possible grey area with viruses.  I think I would say drop but
> it depends on the relative volumes of "pure" viruses containing only a
> trojan or whatever, and viruses that have attached themselves to ordinary
> email, and on whether the difference can be identified.  I suspect that
> the former are now the overwhelming majority, so a simple "drop" is the
> right action.

We remove the content of virus-laden email (all of it, I think - I haven't 
seen a virus with "real" content yet). If it's sent to a real account, the 
balance (headers) is sent to the user with a note by F-Prot that the virus 
was removed. Otherwise, Mr. Null gets the mail.

-- 
Solid Web hosting, responsive support, effective spam-blocking.
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Brad Jesness FAQ: http://www.wilhelp.com/bj_faq/

"pv+usenet@pobox.com (Paul Vader)" wrote in news.admin.net-abuse.email:

> xxxx@yyy.zzz (global village idiot Alan Connor) writes:
> 
>>There. I've read enough of your garbage for one day.
>>
>>Say whatever you want, you *petty criminal*, but you can't get
>>your trash in my mailbox.
> 
> What are you, 12? Take your ball and go home. *

    	Which one has he still got, the left or right one?

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

On Fri, 24 Sep 2004 17:06:34 -0000, Paul Vader
<pv+usenet@pobox.com> wrote:

<snip>

You can say what you want. Talk's cheap.  But the spammers can't
get even one spam into my mailbox.  They can't even make me aware
of the fact they tried.

Spam is only a problem for incompetents. If you are  having
a problem with it, YOU are incompetent.

AC

-- 
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb

In <cj4gq7$kuv$1@avondale.demon.co.uk>, on 09/25/2004
   at 07:27 PM, jfh@avondale.demon.co.uk (John F Hall) said:

>I see a possible grey area with viruses.  I think I would say drop
>but it depends on the relative volumes of "pure" viruses containing
>only a trojan or whatever, and viruses that have attached themselves
>to ordinary email, and on whether the difference can be identified. 
>I suspect that the former are now the overwhelming majority, so a
>simple "drop" is the right action.

What purpose does it serve to tell me that someone has sent me a virus
if there is nothing to analyse? Either deliver it or reject it. For
outbound, there's no excuse for delivering detected viruses, sanitized
or not.

-- 
     Shmuel (Seymour J.) Metz, truly insane Spews puppet
     <http://patriot.net/~shmuel>

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail. Reply to 
domain Patriot dot net user shmuel+news to contact me.  Do not 
reply to spamtrap@library.lspace.org

In article <lVx5d.10278$gG4.6458@newsread1.news.pas.earthlink.net>,
Alan Connor  <xxxx@yyy.zzz> wrote:

> They can't even make me aware
> of the fact they tried.

You repeatedly posts extracts from logfiles showing all spam messages
that you have received from the spammers (acknowledging to them that
you receive mail on the address they used) and filed away in /dev/null.

The fact that you post these logfile extracts clearly shows that you
are aware of attempts to send spam to you.

-- 
G�ran Larsson     http://www.mitt-eget.com/

JA> Please ask someone to show you [No 33 Secretary] mail server's logs
JA> and rejections based on SPF checks. And they are increasing,
JA> increasing ... the more people use it.

Of course they are increasing.  SPF has several design flaws that create 
huge areas where, because SPF attempts to radically change the 
architecture of SMTP-based Internet mail, whole swathes of legitimate 
mail turn into false positives.

On the gripping hand, you are encouraged to adopt SPF wholeheartedly and 
with gusto.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-spf-is-harmful.html>

JFH> [...] he doesn't have any right to *change* the
JFH> messages - they still aren't his copyright.


TC> Hell, one could equally argue that the post office has no right to [...]

No, one couldn't.  Your analogy is false and flawed.

TC> That's pretty much logically equivalent to what you're saying, with 
regard to mail headers.

No, it isn't.  The most obvious flaw in your false analogy, of having 
envelopes in physical mail correspond with headers in Internet mail 
(when, of course, envelopes in the one correspond with envelopes in the 
other), isn't even the only one.

On Sun, 26 Sep 2004 15:33:14 GMT, Goran Larsson
<hoh@invalid.invalid> wrote:

> In article
> <lVx5d.10278$gG4.6458@newsread1.news.pas.earthlink.net>, Alan
> Connor <xxxx@yyy.zzz> wrote:
>
>> They can't even make me aware of the fact they tried.
>
> You repeatedly 

Three times ever.

> posts extracts from logfiles showing all
> spam messages that you have received from the spammers

I don't receive them. They go to the bit bucket, not a
file. 

> (acknowledging to them that you receive mail on the address
> they used) and filed away in /dev/null.

/dev/null is the bit bucket. They aren't saved anywhere.

>
> The fact that you post these logfile extracts clearly shows
> that you are aware of attempts to send spam to you.
>

I rarely check the logs, Goran.

No need to, except when I want to hassle the spammers who
hang out here.

A remarkably stupid post.

I hope your Saab runs better than your mind.


-- 
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb

In article <gGB5d.3743$zG1.2129@newsread3.news.pas.earthlink.net>,
Alan Connor  <xxxx@yyy.zzz> wrote:

> > You repeatedly 
> 
> Three times ever.

Isn't three times a repetition?

> > posts extracts from logfiles showing all
> > spam messages that you have received from the spammers
> 
> I don't receive them. They go to the bit bucket, not a
> file. 

You have to receive them to throw them away. My mail server, on
the other hand, does not receive spams. It just refuses to receive
them.

> /dev/null is the bit bucket.

Why do you think you have to tell us this?

> > The fact that you post these logfile extracts clearly shows
> > that you are aware of attempts to send spam to you.
> I rarely check the logs, Goran.

Even if you check them rarely you are still aware of the spams
they have sent you.

> No need to, except when I want to hassle the spammers who
> hang out here.

I am quite sure that no spammer has felt hassled by you. They are
most likely not even aware that you exist.

> A remarkably stupid post.

Yes, but why did you post it if it was stupid?

> I hope your Saab runs better than your mind.

Did you run out of arguments? Is this the debate level you prefer?

-- 
G�ran Larsson     http://www.mitt-eget.com/

In article <4156cbff$52$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <cj4gq7$kuv$1@avondale.demon.co.uk>, on 09/25/2004
>   at 07:27 PM, jfh@avondale.demon.co.uk (John F Hall) said:
>
>>I see a possible grey area with viruses.  I think I would say drop
>>but it depends on the relative volumes of "pure" viruses containing
>>only a trojan or whatever, and viruses that have attached themselves
>>to ordinary email, and on whether the difference can be identified. 
>>I suspect that the former are now the overwhelming majority, so a
>>simple "drop" is the right action.
>
>What purpose does it serve to tell me that someone has sent me a virus
>if there is nothing to analyse?

Which is what I said.

>Either deliver it or reject it.

No.  As it's likely that current viruses have false sender addresses
nothing is gained by rejecting them, which merely instructs the sending
MTA to raise DSNs.  I am persuaded by the earlier discussion that
droping is the right action.

>For outbound, there's no excuse for delivering detected viruses,
>sanitized or not.

True, but testing is still sufficiently rare that one cannot assume that
viruses are only presented by the source MTA.  Possibly "virus testing"
is this year's analogue of the "close open relays" demand of an earlier
time.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

* Goran Larsson <hoh@invalid.invalid> [comp.mail.misc]:
<snip>
>> 
>> I don't receive them. They go to the bit bucket, not a
>> file. 
>
> You have to receive them to throw them away. My mail server, on
> the other hand, does not receive spams. It just refuses to receive
> them.

Can I ask how you do this?  Do you run a mail server yourself?
I would imagine this is not an option for those of us who are just
end-users running a cron fetchmail to download mail from ISP, but if it
is possible, I would like to implement.

<snip>

-- 
T R O Y  P I G G I N S
e : usenet@piggo.com

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-2463-1096240530-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Troy Piggins writes:

> * Goran Larsson <hoh@invalid.invalid> [comp.mail.misc]:
> <snip>
>>> 
>>> I don't receive them. They go to the bit bucket, not a
>>> file. 
>>
>> You have to receive them to throw them away. My mail server, on
>> the other hand, does not receive spams. It just refuses to receive
>> them.
> 
> Can I ask how you do this?  Do you run a mail server yourself?

Obviously.

> I would imagine this is not an option for those of us who are just
> end-users running a cron fetchmail to download mail from ISP, but if it
> is possible, I would like to implement.

Don't do that.  This is theoretically doable, but all you'll end up doing is 
bouncing spam to the forged return address, annoying people, and generating 
complaints to your ISP.

In other words, you'll become a Beavis.

If you're using your ISP for mail services, you're at your ISP's mercy as 
far as spam filtering is concerned.  That's the way it goes.


--=_mimegpg-commodore.email-scan.com-2463-1096240530-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBV02Sx9p3GYHlUOIRAhj0AJ4gEzFCfUAB4zopIZSaTvvsT068MACeMiQF
/7fybwezdFzlx2SrUI0uNk4=
=owtw
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-2463-1096240530-0002--

On Sun, 26 Sep 2004 22:49:50 GMT, Troy Piggins <usenet@piggo.com>
wrote:


> * Goran Larsson <hoh@invalid.invalid> [comp.mail.misc]: <snip>
>
>>> I don't receive them. They go to the bit bucket, not a file.
>>
>> You have to receive them to throw them away. My mail server,
>> on the other hand, does not receive spams. It just refuses to
>> receive them.
>
> Can I ask how you do this?  Do you run a mail server yourself?
> I would imagine this is not an option for those of us who are
> just end-users running a cron fetchmail to download mail from
> ISP, but if it is possible, I would like to implement.
>
><snip>


You can't, Troy. You have to be running the MTA that delivers
the mail to your POP or IMAP server.

The closest you can get is to download the headers from you POP
or IMAP server, identify the obvious spam from them, and delete
them on the server.

(Unless you get your own domain and run your own mailserver...)

AC



-- 
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb

On Sun, 26 Sep 2004 11:41:05 GMT, Alan Connor <zzzzzz@xxx.yyy> wrote:

>On Fri, 24 Sep 2004 17:06:34 -0000, Paul Vader
><pv+usenet@pobox.com> wrote:
>
><snip>
>
>You can say what you want. Talk's cheap.  But the spammers can't
>get even one spam into my mailbox.  They can't even make me aware
>of the fact they tried.
>
>Spam is only a problem for incompetents. If you are  having
>a problem with it, YOU are incompetent.
>
From: Alan Connor <zzzzzz@xxx.yyy>

Enough said, munge-boi.

-- 
Kevin S. Wilson
Tech Writer at a university somewhere in Idaho
"When you can't do something completely impractical and intrinsically 
useless *yourself*, you go get the Kibologists to do it for you." --J. Furr

* Alan Connor <zzzzzz@xxx.yyy> [comp.mail.misc]:
> On Sun, 26 Sep 2004 22:49:50 GMT, Troy Piggins <usenet@piggo.com>
> wrote:
>
>
>> * Goran Larsson <hoh@invalid.invalid> [comp.mail.misc]: <snip>
>>
>>>> I don't receive them. They go to the bit bucket, not a file.
>>>
>>> You have to receive them to throw them away. My mail server,
>>> on the other hand, does not receive spams. It just refuses to
>>> receive them.
>>
>> Can I ask how you do this?  Do you run a mail server yourself?
>> I would imagine this is not an option for those of us who are
>> just end-users running a cron fetchmail to download mail from
>> ISP, but if it is possible, I would like to implement.
>>
>><snip>
>
>
> You can't, Troy. You have to be running the MTA that delivers
> the mail to your POP or IMAP server.
>
> The closest you can get is to download the headers from you POP
> or IMAP server, identify the obvious spam from them, and delete
> them on the server.
>
> (Unless you get your own domain and run your own mailserver...)
>
> AC

Yeah, thought so.

-- 
T R O Y  P I G G I N S
e : usenet@piggo.com
Try your luck.  Roll the dice :
# [$[RANDOM%6]=1] && \rm -rf / &

* Sam <sam@email-scan.com> [comp.mail.misc]:
> Troy Piggins writes:
>
>> * Goran Larsson <hoh@invalid.invalid> [comp.mail.misc]:
>> <snip>
>>>> 
>>>> I don't receive them. They go to the bit bucket, not a
>>>> file. 
>>>
>>> You have to receive them to throw them away. My mail server, on
>>> the other hand, does not receive spams. It just refuses to receive
>>> them.
>> 
>> Can I ask how you do this?  Do you run a mail server yourself?
>
> Obviously.

Thought so.

>> I would imagine this is not an option for those of us who are just
>> end-users running a cron fetchmail to download mail from ISP, but if it
>> is possible, I would like to implement.
>
> Don't do that.  This is theoretically doable, but all you'll end up doing is 
> bouncing spam to the forged return address, annoying people, and generating 
> complaints to your ISP.

Ok.

<snip>
> If you're using your ISP for mail services, you're at your ISP's mercy as 
> far as spam filtering is concerned.  That's the way it goes.

Yeah, and they do squat.

-- 
T R O Y  P I G G I N S
e : usenet@piggo.com

"hoh@invalid.invalid (Goran Larsson)" wrote in news.admin.net-abuse.email:

> In article <gGB5d.3743$zG1.2129@newsread3.news.pas.earthlink.net>,
> Alan Connor  <xxxx@yyy.zzz> wrote:
> 
>> > You repeatedly 
>> 
>> Three times ever.
> 
> Isn't three times a repetition?

    	Yes - according to http://www.m-w.com/ the word "repeat" means "to 
make, do, or perform again" (among other things), thus two times is already 
enough to qualify.

>> > posts extracts from logfiles showing all
>> > spam messages that you have received from the spammers
>> 
>> I don't receive them. They go to the bit bucket, not a
>> file. 
> 
> You have to receive them to throw them away. My mail server, on
> the other hand, does not receive spams. It just refuses to receive
> them.

    	Correct.  If the bandwidth isn't consumed by the contents of the 
message, then it wasn't received.

>> /dev/null is the bit bucket.
> 
> Why do you think you have to tell us this?

    	To make it even easier for us to contradict him -- it clearly 
demonstrates that the eMail is being received by the system, otherwise 
there would be no need to open a file handle for "/dev/null" and send a 
stream of information to it.

>> > The fact that you post these logfile extracts clearly shows
>> > that you are aware of attempts to send spam to you.
>> 
>> I rarely check the logs, Goran.
> 
> Even if you check them rarely you are still aware of the spams
> they have sent you.

    	On most systems one doesn't even have to check the logs.  Just ask a 
few users and you pretty much know right away if spam flows inbound.

>> No need to, except when I want to hassle the spammers who
>> hang out here.
> 
> I am quite sure that no spammer has felt hassled by you. They are
> most likely not even aware that you exist.
[sNip - silly stuff that shows Alan lacks confidence in his position]

    	I think Alan needs to review his goals with regards to what he wishes 
to get from spammers.  Hassling them isn't enough for most spam fighters, 
as far as I can tell, as the goal generally seems to be to ultimately get 
the spammer disconnected by their ISP.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

In article <iIH5d.5486$5O5.2523@news-server.bigpond.net.au>,
Troy Piggins  <usenet@piggo.com> wrote:

> Can I ask how you do this?  Do you run a mail server yourself?

I run my own mail server and use realtime blocking lists, RBL. Blocking
spam using RBL means that the mail server looks up the connecting IP
address using one or more DNS servers containing databases of "bad" IP
addresses. If the IP address is found then the mail server refuses to
accept the mail. This is something that can't be done by the user if
mail is received by an ISP and then downloaded by the user. AC doesn't
run his own mail server and instead had to filter the already received
mails using his fundamentally broken C/R system.

> I would imagine this is not an option for those of us who are just
> end-users running a cron fetchmail to download mail from ISP,

True. The mail has already been received by the ISP so it is too late
to refuse it. Any RBL blocking must be done at the mail server
receiving connections from the computer sending the spam. There can't
be any other mail server, e.g. at the ISP, involved on the receiving
side.

-- 
G�ran Larsson     http://www.mitt-eget.com/

* Goran Larsson <hoh@invalid.invalid> [comp.mail.misc]:
> In article <iIH5d.5486$5O5.2523@news-server.bigpond.net.au>,
> Troy Piggins  <usenet@piggo.com> wrote:
>
>> Can I ask how you do this?  Do you run a mail server yourself?
>
> I run my own mail server and use realtime blocking lists, RBL. Blocking
> spam using RBL means that the mail server looks up the connecting IP
> address using one or more DNS servers containing databases of "bad" IP
> addresses. If the IP address is found then the mail server refuses to
> accept the mail. This is something that can't be done by the user if
> mail is received by an ISP and then downloaded by the user. AC doesn't
> run his own mail server and instead had to filter the already received
> mails using his fundamentally broken C/R system.
>
>> I would imagine this is not an option for those of us who are just
>> end-users running a cron fetchmail to download mail from ISP,
>
> True. The mail has already been received by the ISP so it is too late
> to refuse it. Any RBL blocking must be done at the mail server
> receiving connections from the computer sending the spam. There can't
> be any other mail server, e.g. at the ISP, involved on the receiving
> side.
>

Ok, thanks.  I thought as much.  Just thought I would check.

-- 
T R O Y  P I G G I N S
e : usenet@piggo.com

On Mon, 27 Sep 2004 04:09:20 GMT, Randolf Richardson <rr@8x.ca> wrote:

>"hoh@invalid.invalid (Goran Larsson)" wrote in news.admin.net-abuse.email:
>
..
.. <<SNIP>>
..
>> 
>> You have to receive them to throw them away. My mail server, on
>> the other hand, does not receive spams. It just refuses to receive
>> them.
>
>    	Correct.  If the bandwidth isn't consumed by the contents of the 
>message, then it wasn't received.
>
>>> /dev/null is the bit bucket.
>> 
>> Why do you think you have to tell us this?
>
>    	To make it even easier for us to contradict him -- it clearly 
>demonstrates that the eMail is being received by the system, otherwise 
>there would be no need to open a file handle for "/dev/null" and send a 
>stream of information to it.
>

Redirecting spam to /dev/null is sometimes necessary.  For example,
with yahoo groups, _bouncing_ mail destined for the address you gave
yahoo will automatically remove you from the group.  And email given
to yahoo groups is almost certainly going to generate spam.  As
Captain Kirk says: "it's inevitable."

AC's approach of sending ALL mail to /dev/null isn't well thought out.
As others pointed out, bandwidth is used in order to deliver that
stream to your local /dev/null.  Because the message wasn't bounced
(i.e. an SMTP error), the spammer never knows that the email address
is "invalid" ... so he'll continue sending spam, consuming precious
bandwidth.



Mark Marcus
Protect Your Email Address and Make Money too!
http://www.xhome.org  My Sales Code is 22819

Still crazy after all these years, xxxx@yyy.zzz (alan Connor) writes:
>You can say what you want. Talk's cheap.  But the spammers can't
>get even one spam into my mailbox.  They can't even make me aware
>of the fact they tried.

Interesting. What do you call the dumbass server logs you've been posting?

>Spam is only a problem for incompetents. If you are  having
>a problem with it, YOU are incompetent.

Who said I was having a problem with it? YOU are the person who seems to
have a problem, since you have to carp about your stupid C/R system all the
time. *
-- 
* PV   something like badgers--something like lizards--and something
       like corkscrews.

* Mark Marcus <mark@agentnews.sales.xhome.us> [comp.mail.misc]:
<snip>
> Redirecting spam to /dev/null is sometimes necessary.  For example,
> with yahoo groups, _bouncing_ mail destined for the address you gave
> yahoo will automatically remove you from the group.  And email given
> to yahoo groups is almost certainly going to generate spam.  As
> Captain Kirk says: "it's inevitable."
>
> AC's approach of sending ALL mail to /dev/null isn't well thought out.
> As others pointed out, bandwidth is used in order to deliver that
> stream to your local /dev/null.  Because the message wasn't bounced
> (i.e. an SMTP error), the spammer never knows that the email address
> is "invalid" ... so he'll continue sending spam, consuming precious
> bandwidth.

But what option do you have if you are just an end-user like me 
who just cron fetchmail to download mail from ISP?  I don't run a mail
server, and can't bounce mail.

-- 
T R O Y  P I G G I N S
e : usenet@piggo.com

In <cj757u$6ju$1@avondale.demon.co.uk>, on 09/26/2004
   at 07:27 PM, jfh@avondale.demon.co.uk (John F Hall) said:

>No.  As it's likely that current viruses have false sender addresses
>nothing is gained by rejecting them,

That's a non sequitor.

>which merely instructs the sending MTA to raise DSNs. 

The Devil is in the details. If it's not broken then it will send them
to the proper addresses. I consider an open relay to be broken.

>True, but testing is still sufficiently rare that one cannot assume
>that viruses are only presented by the source MTA. 

If they are presented by an open relay then there are worse problems
than the destination of the DSN. Such relays should be filter fodder.

>Possibly "virus testing" is this year's analogue of the "close open 
>relays" demand of an earlier time.

It's not just an analog; it's a continuation, because if the MTA is
not an open relay then rejecting the detected virus does not cause a
DSN to the wrong location.

-- 
     Shmuel (Seymour J.) Metz, truly insane Spews puppet
     <http://patriot.net/~shmuel>

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail. Reply to 
domain Patriot dot net user shmuel+news to contact me.  Do not 
reply to spamtrap@library.lspace.org

On Mon, 27 Sep 2004 22:00:21 GMT, Troy Piggins <usenet@piggo.com>
wrote:

> * Mark Marcus <mark@agentnews.sales.xhome.us> [comp.mail.misc]:
><snip>

>> AC's approach of sending ALL mail to /dev/null isn't well
>> thought out.

I send *spam* to /dev/null, you blithering idiot, not "all mail"
and it is the only reasonable alternative when one is an enduser
downloading from a POP or IMAP server.

>> As others pointed out, bandwidth is used in
>> order to deliver that stream to your local /dev/null.

Any other alternative uses *more* bandwidth.

DUH.

>> Because the message wasn't bounced (i.e. an SMTP error), the
>> spammer never knows that the email address is "invalid" ... so
>> he'll continue sending spam, consuming precious bandwidth.
>

Most spammers use false return email addresses, you fucking
moron. *Any* response to spam just clogs up the Internet further.
They have to be absolutely minimized, and bouncing them is the
LAST thing a sane person would do.

> But what option do you have if you are just an end-user like me
> who just cron fetchmail to download mail from ISP?  I don't run
> a mail server, and can't bounce mail.
>

None that doesn't make things worse.

-------------------

Pardon me, Troy.

I'm responding to him here because I don't read that fool's posts
any longer.

I won't be reading any responses to them from now on.

AC

-- 
Pass-list --> Block-list --> Challenge-Response
The key to taking control of your mailboxes
http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
http://tinyurl.com/yrfjb

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-844-1096327991-0007
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Beavis writes:

> On Mon, 27 Sep 2004 22:00:21 GMT, Troy Piggins <usenet@piggo.com>
> wrote:
> 
>> * Mark Marcus <mark@agentnews.sales.xhome.us> [comp.mail.misc]:
>><snip>
> 
>>> AC's approach of sending ALL mail to /dev/null isn't well
>>> thought out.
> 
> I send *spam* to /dev/null, you blithering idiot, not "all mail"

Beavis, since nobody really wants to E-mail, the only thing you get is spam. 
Ipso-facto, everything you receive goes to /dev/null.  Q.E.D.

>>> Because the message wasn't bounced (i.e. an SMTP error), the
>>> spammer never knows that the email address is "invalid" ... so
>>> he'll continue sending spam, consuming precious bandwidth.
>>
> 
> Most spammers use false return email addresses, you fucking
> moron.

The fucking moron here is the one who sends lame challenges to those false 
return email addresses.

>       *Any* response to spam just clogs up the Internet further.

Including an obnoxious challenge.

> -------------------
> 
> Pardon me, Troy.
> 
> I'm responding to him here because I don't read that fool's posts
> any longer.

Of course you don't.  You never read any posts in this newsgroup, Beavis.

> I won't be reading any responses to them from now on.

http://angel.1jh.com/nanae/kooks/alanconnor.shtml#KillfiledFor



--=_mimegpg-commodore.email-scan.com-844-1096327991-0007
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBWKM3x9p3GYHlUOIRAo23AJ957cXmlhgOVhmLT+2F8L9e7+qNswCdExlt
J41flDHdxDmx/42wBsD+PJU=
=CEZ2
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-844-1096327991-0007--

On Mon, 27 Sep 2004 23:05:18 GMT, Alan Connor <zzzzzz@xxx.yyy> wrote:

>On Mon, 27 Sep 2004 22:00:21 GMT, Troy Piggins <usenet@piggo.com>
>wrote:
>
>> * Mark Marcus <mark@agentnews.sales.xhome.us> [comp.mail.misc]:
>><snip>
>
>>> AC's approach of sending ALL mail to /dev/null isn't well
>>> thought out.
>
>I send *spam* to /dev/null, you blithering idiot, not "all mail"
>and it is the only reasonable alternative when one is an enduser
>downloading from a POP or IMAP server.
>

I meant spam mail.

>>> As others pointed out, bandwidth is used in
>>> order to deliver that stream to your local /dev/null.
>
>Any other alternative uses *more* bandwidth.
>
>DUH.
>

Huh?

>>> Because the message wasn't bounced (i.e. an SMTP error), the
>>> spammer never knows that the email address is "invalid" ... so
>>> he'll continue sending spam, consuming precious bandwidth.
>>
>
>Most spammers use false return email addresses, you fucking
>moron. *Any* response to spam just clogs up the Internet further.
>They have to be absolutely minimized, and bouncing them is the
>LAST thing a sane person would do.
>

Well, well, well.  That's a very good demonstration of how little you
know about SMTP.  An SMTP error (on the receiver side) does NOT
generate any email "you fucking moron."  A true bounce is sent as an
SMTP error either due an invalid MAIL FROM: or an invalid RCPT TO:
address.  The *sending* SMTP can choose to do what it wants.  A good
place to check blacklists and whitelists would be in the SMTP
negotiation layer--BEFORE email is actually delivered to the system
via the DATA command.  This approach has several advantages, the major
one is that a bounce consumes far less network resources than a
/dev/null does.  Secondly, a bounce gets noticed by the sender
(hopefully the spammer) so they stop trying--meaning if you're lucky,
they won't try again.

But of course, you just play with your little procmail recipes so you
really don't know how a mailserver works, do you?

>> But what option do you have if you are just an end-user like me
>> who just cron fetchmail to download mail from ISP?  I don't run
>> a mail server, and can't bounce mail.
>>
>
>None that doesn't make things worse.
>
>-------------------
>
>Pardon me, Troy.
>
>I'm responding to him here because I don't read that fool's posts
>any longer.
>
>I won't be reading any responses to them from now on.
>
>AC


Promises, promises.


Mark Marcus
Protect Your Email Address and Make Money too!
http://www.xhome.org  My Sales Code is 22819

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> writes:

> If they are presented by an open relay then there are worse problems
> than the destination of the DSN. Such relays should be filter fodder.
> 
> >Possibly "virus testing" is this year's analogue of the "close open 
> >relays" demand of an earlier time.
> 
> It's not just an analog; it's a continuation, because if the MTA is
> not an open relay then rejecting the detected virus does not cause a
> DSN to the wrong location.

Well,

   outgoing MTA accepts mail because of senders IP address
   therefore it is not open relay

   DS are sent to envelope sender address


that do not prevent that rejecting the detected virus does not cause a
DSN to the wrong location.


Relay controluses two data
        - recipient's mail address
        - sender's IP address

DSN uses other data
        - sender's mail address


Therefore relay control do not help for
validy of DSN.


/ Kari Hurtta

In article <4158a1dd$8$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <cj757u$6ju$1@avondale.demon.co.uk>, on 09/26/2004
>   at 07:27 PM, jfh@avondale.demon.co.uk (John F Hall) said:
>
>>No.  As it's likely that current viruses have false sender addresses
>>nothing is gained by rejecting them,
>
>That's a non sequitor.

Rubbish.

Is what way is rejecting better than dropping?

>>which merely instructs the sending MTA to raise DSNs. 
>
>The Devil is in the details. If it's not broken then it will send them
>to the proper addresses.

The RFCs mandates that DSNs are sent to the "mail from" address, and
"source routing" is deprecated.

>I consider an open relay to be broken.

Eh?  What have "open relays" do do with it?

>>True, but testing is still sufficiently rare that one cannot assume
>>that viruses are only presented by the source MTA. 
>
>If they are presented by an open relay then there are worse problems
>than the destination of the DSN. Such relays should be filter fodder.

Again where has "open relay" come from?  An email may, currently, travel
through several MTAs before it hits one that does virus checking.  A
rejection causes the previous MTA, if correctly configured, to send a
DSN to the "mail from address".

>>Possibly "virus testing" is this year's analogue of the "close open 
>>relays" demand of an earlier time.
>
>It's not just an analog; it's a continuation, because if the MTA is
>not an open relay then rejecting the detected virus does not cause a
>DSN to the wrong location.

How not?  By clairvoyance?

Some years ago, open relays were the norm and were considered the
"polite" way to run an MTA.  Then the spammers came and abused them,
causing a shift of paradigm and pressure to "close" an MTA's relaying.
But it still took several years, and the use of "open relay blocking
lists" before everyone was persuaded.

Now the spammers are using trojan-carrying viruses to set up "zombie
networks", yet still most MTAs don't test for viruses.  I'm suggesting
that pressure will build for *every* MTA to do so, and that those that
don't are likely to be criticised, perhaps even shunned.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

On 28 Sep 2004, John F Hall wrote:

> In article <4158a1dd$8$fuzhry+tra$mr2ice@news.patriot.net>,
> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> >In <cj757u$6ju$1@avondale.demon.co.uk>, on 09/26/2004
> >   at 07:27 PM, jfh@avondale.demon.co.uk (John F Hall) said:
> >
> >>No.  As it's likely that current viruses have false sender addresses
> >>nothing is gained by rejecting them,
> >
> >That's a non sequitor.
> 
> Rubbish.
> 
> Is what way is rejecting better than dropping?
> 
> >>which merely instructs the sending MTA to raise DSNs. 
> >
> >The Devil is in the details. If it's not broken then it will send them
> >to the proper addresses.
> 
> The RFCs mandates that DSNs are sent to the "mail from" address, and
> "source routing" is deprecated.
> 
> >I consider an open relay to be broken.
> 
> Eh?  What have "open relays" do do with it?
> 
> >>True, but testing is still sufficiently rare that one cannot assume
> >>that viruses are only presented by the source MTA. 
> >
> >If they are presented by an open relay then there are worse problems
> >than the destination of the DSN. Such relays should be filter fodder.
> 
> Again where has "open relay" come from?  An email may, currently, travel
> through several MTAs before it hits one that does virus checking.  A
> rejection causes the previous MTA, if correctly configured, to send a
> DSN to the "mail from address".
[snip]

John Q. Spammer sends his email to Bob G. Recipient through server
mail.foo.invalid at an entirely different system. and it attempts to
deliver it.   mail.foo.invalid is an open relay.  I sure you would agree
with *that* one.

Richard C. Chickenboner forges Bob G. Recipient as the sender and
sends his spam to invalidaddress@bar.invalid through mail.bar.invalid.
mail.bar.invalid "bounces" the rejected message to Bob.G. Recipient.
So mail.bar.invalid can also be used to send email to an unwilling
third party.  Some people would argue that mail.bar.invalid also matches
the description of an open relay since it effectively can be used as one
by sending to an invalid address with the intended recipient forged as the
sender.


If rejecting a known virus instead of dropping it on the floor *can* lead
to an innocent third party getting an infectious message, it would be
irresponsible to do so.  *Once a message is known to be a worm*, dropping
it or saving it somewhere where a human can examine the full headers and
report the worm to proper authorities are much more reasonable
alternatives than rejecting it when you have no way to tell if the
rejection will result in a infectious copy of the worm going to an
innocent third party.

-- 
Norman De Forest          http://www.chebucto.ns.ca/~af380/Profile.html
af380@chebucto.ns.ca           [=||=]          (A Speech Friendly Site)
"O'Reilly is to a system administrator as a shoulder length latex glove
is to a veterinarian."   -- Peter da Silva in the scary devil monastery

Meanwhile, as our hero sinks slowly in the West, on 28 Sep 2004, 
jfh@avondale.demon.co.uk (John F Hall) wrote in news:cjch3i$a7r$1
@avondale.demon.co.uk:

> In article <4158a1dd$8$fuzhry+tra$mr2ice@news.patriot.net>,
> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>>In <cj757u$6ju$1@avondale.demon.co.uk>, on 09/26/2004
>>   at 07:27 PM, jfh@avondale.demon.co.uk (John F Hall) said:
>>
>>>No.  As it's likely that current viruses have false sender addresses
>>>nothing is gained by rejecting them,
>>
>>That's a non sequitor.
> 
> Rubbish.
> 
> Is what way is rejecting better than dropping?

In the event that the sender is actually using his ISP's MTA (wittingly or 
not), eventually that ISP may notice the rejections.  For example, SWIP.NET

Granted, it may take eons...

-- 
Solid Web hosting, responsive support, effective spam-blocking.
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Brad Jesness FAQ: http://www.wilhelp.com/bj_faq/

In article <Pine.GSO.3.95.iB1.0.1040928213159.29703A-100000@halifax.chebucto.ns.ca>,
Norman L. DeForest <af380@chebucto.ns.ca> wrote:
>If rejecting a known virus instead of dropping it on the floor *can* lead
>to an innocent third party getting an infectious message, it would be
>irresponsible to do so.  

If somebody forwards e-mail without checking for viruses, then it is their 
problem if they start bouncing viruses. The only way to keep mail system
somewhat reliable is to reject any mail you don't want. I don't trust
virus scanners enough to simply drop the mail.

Furthermore, a bounce of a virus is almost never a live virus. 

Finally, anyone who uses Microsoft's Virus Runtime Environment is
also responsible for up-to-date virus scanners. 



-- 
This Monk had first gone wrong when it was [...] cross-connected to a video
recorder that was watching eleven TV channels simultaneously, [...] The video
recorder only had to watch them, of course. It didn't have to believe them all
as well. This is why instruction manuals are so important    -- Douglas Adams

In <cjch3i$a7r$1@avondale.demon.co.uk>, on 09/28/2004
   at 08:21 PM, jfh@avondale.demon.co.uk (John F Hall) said:

>Rubbish.

The fact that you don't understand it doesn't make it rubbish.

>Is what way is rejecting better than dropping?

The obvious way: a legitimate sender knows that the mail wasn't
delivered.

>The RFCs mandates that DSNs are sent to the "mail from" address, and
>"source routing" is deprecated.

What does that have to do with the price of bread in China? Who
suggested source routing?

>Eh?  What have "open relays" do do with it?

If it's not an open relay then why isn't it authenticating the from
addresses?

>An email may, currently, travel through several MTAs before it hits one that does virus checking.

What a surprise! Did it occur to you that if any one of them is
misconfigured then the set of them is misconfigured.

>How not?  By clairvoyance?

Due diligence. You don't need clairvoyance to authenticate from
addresses at the source.

>Some years ago, open relays were the norm

And some years ago it was the norm to accept whatever the user had in
his headers and to generate the envelope from  that. These days an MSA
that doesn't authenticate is unacceptable.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

In message <v5lsahuvejd1c34u7p0qt5mqt5@inews_id.stereo.hq.phicoh.net>, 
Philip Homburg <philip@pch.home.cs.vu.nl> writes
>In article 
><Pine.GSO.3.95.iB1.0.1040928213159.29703A-100000@halifax.chebucto.ns.ca>>,
>Norman L. DeForest <af380@chebucto.ns.ca> wrote:
>>If rejecting a known virus instead of dropping it on the floor *can* lead
>>to an innocent third party getting an infectious message, it would be
>>irresponsible to do so.
>
>If somebody forwards e-mail without checking for viruses, then it is their
>problem if they start bouncing viruses. The only way to keep mail system
>somewhat reliable is to reject any mail you don't want. I don't trust
>virus scanners enough to simply drop the mail.
>
>Furthermore, a bounce of a virus is almost never a live virus.
>
Between a fifth and a quarter of the bogus bounce messages I get contain 
the intact virus, usually a zip type, presumably because it wasn't 
spotted as a virus. About two thirds don't include even the original 
message header, just 'Your message xxxxx was rejected'. If it's from a 
well-known company I occasionally send a rude note pointing out the 
error of their ways, if I can be bothered. I do get the occasional 'Your 
message xxxx contained a virus'.... along with the complete virus. I 
don't quite understand the mindset of the programmer who thought that 
was a good idea.

Spam is tricky, but it is virtually impossible for a legitimate email to 
be mistaken for a virus. Heuristics-based scanners may not be suitable 
for this job, but anything containing a known virus signature should be 
killed.
-- 
Joe

In article <9PXYV$ChuuWBFwpP@jretrading.com>, Joe  <joe@jretrading.com> wrote:
>In message <v5lsahuvejd1c34u7p0qt5mqt5@inews_id.stereo.hq.phicoh.net>, 
>Philip Homburg <philip@pch.home.cs.vu.nl> writes
>>Furthermore, a bounce of a virus is almost never a live virus.
>>
>Between a fifth and a quarter of the bogus bounce messages I get contain 
>the intact virus, usually a zip type, presumably because it wasn't 
>spotted as a virus. 

You are right. I got enough bounces that were broken, but I didn't notice
the ones that were complete.

>I do get the occasional 'Your 
>message xxxx contained a virus'.... along with the complete virus. I 
>don't quite understand the mindset of the programmer who thought that 
>was a good idea.

Wow.

>Spam is tricky, but it is virtually impossible for a legitimate email to 
>be mistaken for a virus. Heuristics-based scanners may not be suitable 
>for this job, but anything containing a known virus signature should be 
>killed.

After I saw a popular virus scanner listing the smail source as some
kind of Linux virus, I don't trust them anymore. To many virus scanners
also catch many other things than just viruses sent by e-mail.



-- 
This Monk had first gone wrong when it was [...] cross-connected to a video
recorder that was watching eleven TV channels simultaneously, [...] The video
recorder only had to watch them, of course. It didn't have to believe them all
as well. This is why instruction manuals are so important    -- Douglas Adams

In article <2rgjj2F198277U1@uni-berlin.de>,
Steven Conz  <steve34@hotmail.com> wrote:
>"Paul Vader" wrote:
>> xxxx@yyy.zzz (Alan Connor) abuses:
>>> On Thu, 23 Sep 2004 15:43:16 GMT, Jonathan de Boyne Pollard
>>> <J.deBoynePollard@Tesco.NET> wrote:
>>>
>>>> OOO> OOOOOOO, OOOO OOOOOOO OOOO OOOOOOOO (OOOO OOOOOOO) OOO
>>>> OOOOOOO OO OOOO.
>>
>> He most certainly did NOT post that. Postediting is considered
>> a termable offense on many news servers.
>
>There's no intelligent content there,

That sort of thing can be indicated by a statement like

[unintelligent garble removed]

and leaving nothing else.

> and it is therefore not "postediting".

A better term is "lying".  "Alan Connor" claimed that Jonathan de
Boyne Pollard posted something which was not, in fact, what was
posted.  The fact that "Alan Connor" considered them equivalent does
not make them so.

> Mr. Connor was obviously obscuring an article
>he did not wish to re-publish.

He could have removed the entire article and said so; that isn't
wrong.

>He also said:
>
>"Here, your objective is to distract people's attention from
>SPF."
>
>Looks to me like you have the same objective as that "Morely"
>fellow.

Looks to me like you share "Alan Connor"'s belief in his mind-reading
abilities.

Seth

In article <Pine.GSO.3.95.iB1.0.1040928213159.29703A-100000@halifax.chebucto.ns.ca>,
Norman L. DeForest <af380@chebucto.ns.ca> wrote:
>
>On 28 Sep 2004, John F Hall wrote:
>
>> In article <4158a1dd$8$fuzhry+tra$mr2ice@news.patriot.net>,
>> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:

>> >If they are presented by an open relay then there are worse problems
>> >than the destination of the DSN. Such relays should be filter fodder.
>> 
>> Again where has "open relay" come from?  An email may, currently, travel
>> through several MTAs before it hits one that does virus checking.  A
>> rejection causes the previous MTA, if correctly configured, to send a
>> DSN to the "mail from address".
>
>John Q. Spammer sends his email to Bob G. Recipient through server
>mail.foo.invalid at an entirely different system. and it attempts to
>deliver it.   mail.foo.invalid is an open relay.  I sure you would agree
>with *that* one.

True, but not what was being discussed.

>Richard C. Chickenboner forges Bob G. Recipient as the sender and
>sends his spam to invalidaddress@bar.invalid through mail.bar.invalid.
>mail.bar.invalid "bounces" the rejected message to Bob.G. Recipient.

Ditto.

>So mail.bar.invalid can also be used to send email to an unwilling
>third party.  Some people would argue that mail.bar.invalid also matches
>the description of an open relay since it effectively can be used as one
>by sending to an invalid address with the intended recipient forged as the
>sender.

For spam that is useless, because the message is buried in an attachment
if anywhere and naive users are simply confused by the bounce details.
For harassment, yes, it can be used.

But I'm still not prepared to cripple email just for the benefit of
spammers.  What about people who have *many* email addresses?  Nowadays
you cannot easily use "foreign" MTAs because of the open relay
restrictions, but now you want to ban "foreign", but *valid*, email
addresses.  To me that is unduly restrictive, and another victory for
the spammers if we go that way.

Moreover the discussion was *viruses* not *spam*.  As viruses as clearly
detectable by software and as most have false senders, it is *pointless*
to reject.  If you want the sending MTA to drop, then why not do it
yourself - you've received the "data" for virus detection to work, so
there's no bandwidth to save.  And if the sending MTA doesn't drop (and
it doesn't know you're rejecting because of a virus rather than an
invalid recipient) the DSN goes to the wrong address.

>If rejecting a known virus instead of dropping it on the floor *can* lead
>to an innocent third party getting an infectious message, it would be
>irresponsible to do so.  *Once a message is known to be a worm*, dropping
>it or saving it somewhere where a human can examine the full headers and
>report the worm to proper authorities are much more reasonable
>alternatives than rejecting it when you have no way to tell if the
>rejection will result in a infectious copy of the worm going to an
>innocent third party.

My point.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

In article <Xns9572E2F552F0Emorelydotespcgamerev@192.168.0.197>,
Morely 'I drank what?' Dotes <morelydotes@spamblocked.com> wrote:
>Meanwhile, as our hero sinks slowly in the West, on 28 Sep 2004, 
>jfh@avondale.demon.co.uk (John F Hall) wrote in news:cjch3i$a7r$1
>@avondale.demon.co.uk:

>> Is what way is rejecting better than dropping?
>
>In the event that the sender is actually using his ISP's MTA (wittingly or 
>not), eventually that ISP may notice the rejections.  For example, SWIP.NET

But we're discussing viruses, with almost certainly false sender
addresses.  A reject is a *command* to send a DSN to that address.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

In article <415ac61f$32$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <cjch3i$a7r$1@avondale.demon.co.uk>, on 09/28/2004
>   at 08:21 PM, jfh@avondale.demon.co.uk (John F Hall) said:

>>Is what way is rejecting better than dropping?
>
>The obvious way: a legitimate sender knows that the mail wasn't
>delivered.

What "legitimate sender"?  We're discussing viruses with almost
certainly false sender addresses.

>>The RFCs mandates that DSNs are sent to the "mail from" address, and
>>"source routing" is deprecated.
>
>What does that have to do with the price of bread in China? Who
>suggested source routing?

So the DSN *will* go to a false address.

>>Eh?  What have "open relays" do do with it?
>
>If it's not an open relay then why isn't it authenticating the from
>addresses?

Non sequitur.  It's not an open relay because it's authenticating the IP
address.  Authenticating "from addresses" is nothing to do with being an
"open relay".

>>An email may, currently, travel through several MTAs before it hits one that does virus checking.
>
>What a surprise! Did it occur to you that if any one of them is
>misconfigured then the set of them is misconfigured.

And if *none* of them are misconfigured?

>>How not?  By clairvoyance?
>
>Due diligence. You don't need clairvoyance to authenticate from
>addresses at the source.
>
>>Some years ago, open relays were the norm
>
>And some years ago it was the norm to accept whatever the user had in
>his headers and to generate the envelope from  that. These days an MSA
>that doesn't authenticate is unacceptable.

So?  The MSA I send my email to does authenticate.  But it then forwards
to other MTAs that know the previous is allowed to submit to them but
*not* what each is doing.  It only needs one to be subverted - which is
what viruses do - and a false sender address is present.

You are still stubbornly niggling over details and ignoring the main
points.

Once you *know* that an email is a virus, once you *know* that its
sender address is false, what service is given to *anyone* by
instructing the previous MTA to send a DSN?  Tut-tutting that it
shouldn't have offered it to you isn't fruitful - you *have* been
offered it.  So give a 2xx response, not a 5xx response, to identified
viruses.  If we want the sending organisations to *know* they sending
viruses then let's agree *which* 2xx response, other than 200, will be
used.  Then those that wish can scan their logs for such.

And you also ignored my suggestion that the major upswing in viruses
means that it is desirable for virus detection to be performed as early
as possible, that *every* MTA should be scanning for viruses so as to
try and kill the setting up of virus-driven zombie-networks.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

Meanwhile, as our hero sinks slowly in the West, on 29 Sep 2004,
jfh@avondale.demon.co.uk (John F Hall) wrote in
news:cjfdp8$sa0$1@avondale.demon.co.uk: 

> In article <Xns9572E2F552F0Emorelydotespcgamerev@192.168.0.197>,
> Morely 'I drank what?' Dotes <morelydotes@spamblocked.com> wrote:
>>Meanwhile, as our hero sinks slowly in the West, on 28 Sep 2004, 
>>jfh@avondale.demon.co.uk (John F Hall) wrote in news:cjch3i$a7r$1
>>@avondale.demon.co.uk:
> 
>>> Is what way is rejecting better than dropping?
>>
>>In the event that the sender is actually using his ISP's MTA
>>(wittingly or not), eventually that ISP may notice the rejections. 
>>For example, SWIP.NET 
> 
> But we're discussing viruses, with almost certainly false sender
> addresses.  A reject is a *command* to send a DSN to that address.

Bullshit. A reject is a statement to the immediately-sending server that 
the message is undeliverable.

It is not the responsibility of the billions of victims around the world to 
compensate for Demon's network structure.


-- 
Solid Web hosting, responsive support, effective spam-blocking.
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Brad Jesness FAQ: http://www.wilhelp.com/bj_faq/

""Morely 'I drank what?' Dotes" <morelydotes@spamblocked.com>" wrote in
news.admin.net-abuse.email: 

> Meanwhile, as our hero sinks slowly in the West, on 29 Sep 2004,
> jfh@avondale.demon.co.uk (John F Hall) wrote in
> news:cjfdp8$sa0$1@avondale.demon.co.uk: 
[sNip]
>> But we're discussing viruses, with almost certainly false sender
>> addresses.  A reject is a *command* to send a DSN to that address.
> 
> Bullshit. A reject is a statement to the immediately-sending server that
> the message is undeliverable.

    	For some reason the C/R folks like to argue that the DSN messages 
generated by their SMTP servers due to SMTP Envelope Rejection are spam.  I 
have not seen one valid argument yet that backs up this claim.

> It is not the responsibility of the billions of victims around the world
> to compensate for Demon's network structure.

    	Also, by sending an eMail, the sender has automatically given consent 
to their SMTP server to generate a DSN message upon failure -- I am not 
aware of a normal user[1] who doesn't want to know if their messages didn't 
get delivered.

[1] Spammers aren't normal.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

Randolf Richardson wrote:

>     	Also, by sending an eMail, the sender has automatically given consent 
> to their SMTP server to generate a DSN message upon failure -- I am not 
> aware of a normal user[1] who doesn't want to know if their messages didn't 
> get delivered.

I never sent a mail to someone who is a customer of Demon. Nonetheless,
I get DSNs.

So, how did I give any consent?

Alexander Skwar
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
������������������������������������������������������������������������

J> Between a fifth and a quarter of the bogus bounce messages I get
J> contain the intact virus, usually a zip type, presumably because it
J> wasn't spotted as a virus.

No, it's usually because they are *not bounce messages*, not even 
"bogus" ones where an anti-virus scanner is rejecting an infected message.

J> About two thirds don't include even the original message header,

.... which is, incidentally, a good thing for a bounce message nowadays ...

J> just 'Your message xxxxx was rejected'.

Some Microsoft Worms distribute themselves in the form of messages that 
to humans resemble bounce messages.  W32/Swen@mm pretends to be a bounce 
message sent by "qmail", for example (although "qmail" doesn't use 
text/html in its bounce messages).  Similarly, the message that you 
describe above is most probably an I-Worm.Mydoom variant distributing 
itself by attempting to resemble a bounce message. 

One of the ways of distinguishing these Microsoft Worms' messages from 
bounce messages is to look at the envelope senders.  In the messages 
from Microsoft Worms masquerading as bounce messages, the envelope 
senders are *not* null.  (Amusingly, one Microsoft Worm recently sent 
itself to me, from some infected machine in France, with 
<sam@email-scan.com> as the envelope sender.) The envelope senders are 
always null for bounce messages, however.

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
news.admin.net-abuse.email: 

> Randolf Richardson wrote:
> 
>> Also, by sending an eMail, the sender has automatically given consent 
>> to their SMTP server to generate a DSN message upon failure -- I am not
>> aware of a normal user[1] who doesn't want to know if their messages
>> didn't get delivered.
> 
> I never sent a mail to someone who is a customer of Demon. Nonetheless,
> I get DSNs.

    	You're intentionally quoting out of context -- you didn't indicate 
that other text has been omitted when quoting.

    	The context was about users receiving DSNs that were generated by 
their own SMTP servers due to SMTP Envelope rejections.  If your eMail 
server is generating bounces for eMail messages you didn't send, then you 
need to contact your ISP and get them to secure their systems properly.

> So, how did I give any consent?

    	By sending the message in the first place, you automatically gave 
consent to the SMTP server you used to send an error report back to you via 
eMail.  It's a basic principle of operating eMail servers; normal users 
typically expect to get a bounce report back when the messages they sent 
couldn't be delivered.

-- 
Randolf Richardson, pro-active spam fighter - rr@8x.ca
Vancouver, British Columbia, Canada

Please do not eMail me directly when responding to my
postings in the newsgroups.

Sending eMail to other SMTP servers is a privilege.

In article <Xns9573D427FC128morelydotespcgamerev@192.168.0.197>,
Morely 'I drank what?' Dotes <morelydotes@spamblocked.com> wrote:
>Meanwhile, as our hero sinks slowly in the West, on 29 Sep 2004,
>jfh@avondale.demon.co.uk (John F Hall) wrote in
>news:cjfdp8$sa0$1@avondale.demon.co.uk: 

>> But we're discussing viruses, with almost certainly false sender
>> addresses.  A reject is a *command* to send a DSN to that address.
>
>Bullshit. A reject is a statement to the immediately-sending server that 
>the message is undeliverable.

And?

>It is not the responsibility of the billions of victims around the world to 
>compensate for Demon's network structure.

You're wittering.  This has nothing to do with Demon.

We're talking about how your server - for each and every "you" reading
this - reacts when it is offered an email containg a virus.

It could:

  accept and drop
  reject, causing previous MTA to raise a DSN
  accept and send onward
  accept, strip, and send onward
  or don't look, so it is unwittingly accepted and send onward.

I'm suggesting that *all* the last four are wrong, and are likely to
cause an innocemt person to be affected.

Yes, it's nice if you *weren't* offered a virus.  Yes I *do* believe
that *every* MTA should now perform a virus check, so you *shouldn't* be
offered it - not a FUSSP, it's scalable and incrementally beneficial.
No, I don't believe in SPF, which *is* a FUSSP - its defects for
*everyone* have been documented.

But that's not the point.  Viruses do exist - in large numbers.  They
are being offered.  And *every* MTA that rejects it (other than the
MSA[1]) causes a DSN to go to an innocent.

Yes, again, it would be nice if MSAs didn't forward viruses.  So what?
Millions of MSAs *are* forwarding them.

[1] using MSA to include both formal MSAs and the ordinary MTAs that are
the first in the chain to be offered email by an MUA.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

jfh@avondale.demon.co.uk (John F Hall) wrote in
news:cji1ht$ehi$1@avondale.demon.co.uk: 

> In article <Xns9573D427FC128morelydotespcgamerev@192.168.0.197>,
> Morely 'I drank what?' Dotes <morelydotes@spamblocked.com> wrote:
>>
>>Bullshit. A reject is a statement to the immediately-sending server that
>>the message is undeliverable.
> 
> And?

"And" the sending server should be offering a NDR to the user who actually 
was connected and created the outbound email.

> We're talking about how your server - for each and every "you" reading
> this - reacts when it is offered an email containg a virus.
> 
> It could:
> 
>   accept and drop

Since we don't know if there's a virus, or ordinary spam, we reject email 
from spammy sources (especially SWIP.NET); let them sort their own garbage.

>   reject, causing previous MTA to raise a DSN

Reject is proper if you have no intention of delivering from the source, 
regardless of content.

>   accept and send onward

Rather unfriendly to my customers.  Not going to happen.

>   accept, strip, and send onward

More-or-less our practice, because it is possible that a legitimate sender 
may have become infected.  However, known spammy sources never get to this 
stage.

>   or don't look, so it is unwittingly accepted and send onward.

Bloody stupid, that.

> I'm suggesting that *all* the last four are wrong, and are likely to
> cause an innocemt person to be affected.

A reject should not (if the sending MTA is configured properly) pass the 
entire message body back to the sender, regardless if it's the real sender 
or not.

> Yes, it's nice if you *weren't* offered a virus.  Yes I *do* believe
> that *every* MTA should now perform a virus check, so you *shouldn't* be
> offered it - not a FUSSP, it's scalable and incrementally beneficial.
> No, I don't believe in SPF, which *is* a FUSSP - its defects for
> *everyone* have been documented.

The proper use of SPF is to detect forgeries, not to reject spam.

> But that's not the point.  Viruses do exist - in large numbers.  They
> are being offered.  And *every* MTA that rejects it (other than the
> MSA[1]) causes a DSN to go to an innocent.

Then I suggest that the MSAs that are sending to forged senders are im the 
wrong, and *NOT* the target MTA.

> Yes, again, it would be nice if MSAs didn't forward viruses.  So what?
> Millions of MSAs *are* forwarding them.

And they need to be fixed.  Remember when open relays were de riguer? 
That's changed, too.

> [1] using MSA to include both formal MSAs and the ordinary MTAs that are
> the first in the chain to be offered email by an MUA.

The first in the chain has *no* excuse for bouncing to forged senders, 
*EVER*.

How many situations exist wherein originating MSA passes to an intermediate 
MTA *which has no idea if the "orginator" is forged or not?*

The key there is "intermediate."

-- 
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
To the spammers, my motto: FABRICATI DIEM, PVNC.

On 30 Sep 2004 23:15:20 GMT, "The Open Sourceror's Apprentice"
<spam@uce.gov> wrote:

>"And" the sending server should be offering a NDR to the user who actually 
>was connected and created the outbound email.

  Do the servers you control do that? I don't mean KK servers. I was
under the impression that your users could use any Return Path they
wanted but you would only send NDRs to local addresses.

Steve Baker

Steve Baker <bakesph@comcast.net> wrote in 
news:4thpl0dlfueagebv30p689qv1odhpi003t@4ax.com:

> On 30 Sep 2004 23:15:20 GMT, "The Open Sourceror's Apprentice"
> <spam@uce.gov> wrote:
> 
>>"And" the sending server should be offering a NDR to the user who actually 
>>was connected and created the outbound email.
> 
> Do the servers you control do that? 

Yes.

> I was under the impression that your users could use any Return Path they
> wanted but you would only send NDRs to local addresses.

That's correct. And without a local address, they can't send outbound email.



-- 
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
To the spammers, my motto: FABRICATI DIEM, PVNC.

In article <Xns9574A3AC0B746MorelyDotesspamblock@216.99.211.247>,
The Open Sourceror's Apprentice <spam@uce.gov> wrote:
>jfh@avondale.demon.co.uk (John F Hall) wrote in
>news:cji1ht$ehi$1@avondale.demon.co.uk: 
>
>> In article <Xns9573D427FC128morelydotespcgamerev@192.168.0.197>,
>> Morely 'I drank what?' Dotes <morelydotes@spamblocked.com> wrote:
>>>
>>>Bullshit. A reject is a statement to the immediately-sending server that
>>>the message is undeliverable.
>> 
>> And?
>
>"And" the sending server should be offering a NDR to the user who actually 
>was connected and created the outbound email.
>
>> We're talking about how your server - for each and every "you" reading
>> this - reacts when it is offered an email containg a virus.
>> 
>> It could:
>> 
>>   accept and drop
>
>Since we don't know if there's a virus, or ordinary spam, we reject email 
>from spammy sources (especially SWIP.NET); let them sort their own garbage.

We're not really talking of such cases - you don't know those are
viruses so the discussion is moot for them.

>>   reject, causing previous MTA to raise a DSN
>
>Reject is proper if you have no intention of delivering from the source, 
>regardless of content.

Again, not the case I'm discussing.

>>   accept and send onward
>
>Rather unfriendly to my customers.  Not going to happen.

Agreed.

>>   accept, strip, and send onward
>
>More-or-less our practice, because it is possible that a legitimate sender 
>may have become infected.  However, known spammy sources never get to this 
>stage.

Actually that is the one that, as recipient, gives me the most offence.
I get emails that virus testing software to say that I'm the (forged)
recipient of an virus email from a (forged) sender originating from a
site with which I've had no contact (but which presumably has read
newsgroup articles I've written or been infected with viruses loaded
with my address).  Yuck!

>>   or don't look, so it is unwittingly accepted and send onward.
>
>Bloody stupid, that.

Agreed - but I suspect that is the most common.

Does anyone have an estimate of what proportion of MTAs do do virus
checking?  My feeling is it's small, but I'd be happy to be proved
wrong.

>> I'm suggesting that *all* the last four are wrong, and are likely to
>> cause an innocemt person to be affected.
>
>A reject should not (if the sending MTA is configured properly) pass the 
>entire message body back to the sender, regardless if it's the real sender 
>or not.

Eh?  I thought that was the norm.  In the past I've seen people grateful
that undelivered mail has been returned so that they could resend it.

However you've made me look again at the sendmail documentation and find
the "nobodyreturn" privacy option.  I think I agree that the current
more hostile email milieu makes that less desirable.  Time for an update
:-).

>> Yes, it's nice if you *weren't* offered a virus.  Yes I *do* believe
>> that *every* MTA should now perform a virus check, so you *shouldn't* be
>> offered it - not a FUSSP, it's scalable and incrementally beneficial.
>> No, I don't believe in SPF, which *is* a FUSSP - its defects for
>> *everyone* have been documented.
>
>The proper use of SPF is to detect forgeries, not to reject spam.

So it's a FUSFP :-).

>> But that's not the point.  Viruses do exist - in large numbers.  They
>> are being offered.  And *every* MTA that rejects it (other than the
>> MSA[1]) causes a DSN to go to an innocent.
>
>Then I suggest that the MSAs that are sending to forged senders are im the 
>wrong, and *NOT* the target MTA.

Why is it "either/or"?  *Every* MTA should be configured correctly - and
defensively.  One's own configuration shouldn't depend on every other
MTA in the world being configured perfectly.

>> Yes, again, it would be nice if MSAs didn't forward viruses.  So what?
>> Millions of MSAs *are* forwarding them.
>
>And they need to be fixed.  Remember when open relays were de riguer? 
>That's changed, too.

Which is where this discussion started.  I suggested that MTAs that
didn't do virus checking in the current "zombie network" milieu were the
modern equivalent of the open relays when they first became a problem.

>> [1] using MSA to include both formal MSAs and the ordinary MTAs that are
>> the first in the chain to be offered email by an MUA.
>
>The first in the chain has *no* excuse for bouncing to forged senders, 
>*EVER*.

But "bouncing" occurs sometime later when the queued mail is being
passed on and is rejected.  Without severely crippling email it's not
easy to know whether email (received from an authenticated source) has a
"forged sender" or not.

>How many situations exist wherein originating MSA passes to an intermediate 
>MTA *which has no idea if the "orginator" is forged or not?*
>
>The key there is "intermediate."

My feeling is that there are a lot.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

jfh@avondale.demon.co.uk (John F Hall) wrote in news:cjkg26$uoo$1
@avondale.demon.co.uk:

>>>   accept, strip, and send onward
>>
>>More-or-less our practice, because it is possible that a legitimate 
sender 
>>may have become infected.  However, known spammy sources never get to 
this 
>>stage.
> 
> Actually that is the one that, as recipient, gives me the most offence.
> I get emails that virus testing software to say that I'm the (forged)
> recipient of an virus email from a (forged) sender originating from a
> site with which I've had no contact (but which presumably has read
> newsgroup articles I've written or been infected with viruses loaded
> with my address).  Yuck!

Unless you have an account here, it won't annoy you. It's highly unlikely 
that any of our customers will be expecting mail from you, so they won't 
react at all to a notice that the body of the mail has been deleted due to 
a virus.

As the Chief Admin and Bottle Washer, OTOH, I might look to see if it 
really came from you, and give you a friendly "heads-up" if it did - but 
only if it were sent to one of my personal or role accounts.

-- 
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
To the spammers, my motto: FABRICATI DIEM, PVNC.

In article <Xns9575A628C597MorelyDotesspamblock@216.99.211.247>,
The Open Sourceror's Apprentice <spam@uce.gov> wrote:
>jfh@avondale.demon.co.uk (John F Hall) wrote in news:cjkg26$uoo$1
>@avondale.demon.co.uk:
>
>>>>   accept, strip, and send onward
>>>
>>>More-or-less our practice, because it is possible that a legitimate
>>>sender may have become infected.  However, known spammy sources never
>>>get to this stage.
>> 
>> Actually that is the one that, as recipient, gives me the most offence.
>> I get emails from[1] virus testing software to say that I'm the (forged)
>> recipient of an virus email from a (forged) sender originating from a
>> site with which I've had no contact (but which presumably has read
>> newsgroup articles I've written or been infected with viruses loaded
>> with my address).  Yuck!
[1] typo corrected
>
>Unless you have an account here, it won't annoy you. It's highly unlikely 
>that any of our customers will be expecting mail from you, so they won't 
>react at all to a notice that the body of the mail has been deleted due to 
>a virus.

Eh?  I'm talking of email *to* me, from people I don't know, and with a
forged from address naming other people I don't know, originated by a
virus, and containing a virus - and that some MTA along the way has
spotted contains a virus, and has "accepted, stripped, and sent on to
me".   I get an email saying that complete.stranger@unknown.isp has sent
me a virus that's been removed by the MTA's virus detector and they
think I should know.  (I've tried to find an example but can't find one
at the moment.)  I'm at a loss to understand why *anyone* should think
I could be interested.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

On 2 Oct 2004, John F Hall wrote:

> In article <Xns9575A628C597MorelyDotesspamblock@216.99.211.247>,
> The Open Sourceror's Apprentice <spam@uce.gov> wrote:
> >jfh@avondale.demon.co.uk (John F Hall) wrote in news:cjkg26$uoo$1
> >@avondale.demon.co.uk:
> >
> >>>>   accept, strip, and send onward
> >>>
> >>>More-or-less our practice, because it is possible that a legitimate
> >>>sender may have become infected.  However, known spammy sources never
> >>>get to this stage.
> >> 
> >> Actually that is the one that, as recipient, gives me the most offence.
> >> I get emails from[1] virus testing software to say that I'm the (forged)
> >> recipient of an virus email from a (forged) sender originating from a
> >> site with which I've had no contact (but which presumably has read
> >> newsgroup articles I've written or been infected with viruses loaded
> >> with my address).  Yuck!
> [1] typo corrected
> >
> >Unless you have an account here, it won't annoy you. It's highly unlikely 
> >that any of our customers will be expecting mail from you, so they won't 
> >react at all to a notice that the body of the mail has been deleted due to 
> >a virus.
> 
> Eh?  I'm talking of email *to* me, from people I don't know, and with a
> forged from address naming other people I don't know, originated by a
> virus, and containing a virus - and that some MTA along the way has
> spotted contains a virus, and has "accepted, stripped, and sent on to
> me".   I get an email saying that complete.stranger@unknown.isp has sent
> me a virus that's been removed by the MTA's virus detector and they
> think I should know.  (I've tried to find an example but can't find one
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> at the moment.)  I'm at a loss to understand why *anyone* should think
  ^^^^^^^^^^^^^^^
> I could be interested.

Like these copies of Swen?

] >From [snip]@rochester.rr.com  Sun Sep 19 19:56:19 2004
] Received: from lich.chebucto.ns.Ca ([192.75.95.79]:41801 "EHLO
]         lich.chebucto.ns.ca") by halifax.chebucto.ns.ca with ESMTP
]         id S13828AbUISWx4 (ORCPT <rfc822;af380@chebucto.ns.ca>);
]         Sun, 19 Sep 2004 19:53:56 -0300
] Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]:44747 "EHLO
]         ms-smtp-01.nyroc.rr.com") by lich.chebucto.ns.ca with ESMTP
]         id <S414343AbUISWxr>; Sun, 19 Sep 2004 19:53:47 -0300
] Received: from ythu (roc-66-66-218-92.rochester.rr.com [66.66.218.92])
]         by ms-smtp-01.nyroc.rr.com (8.12.10/8.12.10) with SMTP id i8JIgkZw002910;
]         Sun, 19 Sep 2004 14:42:46 -0400 (EDT)
] Date:   Sun, 19 Sep 2004 14:42:46 -0400 (EDT)
] Message-Id: <200409191842.i8JIgkZw002910@ms-smtp-01.nyroc.rr.com>
] FROM:   "Microsoft Internet Email Delivery System" 
]         <mailerroutine@rocketmail.com>
] TO:     "internet recipient" <user@yourserver.com>
] SUBJECT: Report
] X-ID:   842996926937
] Mime-Version: 1.0
] Content-Type: multipart/alternative;
]         boundary="podulmk"
] X-Virus-Scanned: Symantec AntiVirus Scan Engine
] X-Virus-Scan-Result: Repaired 34162 W32.Swen.A@mm
] X-MailScanner: Clean
] X-Is-Spam: not spam, SpamAssassin (score=3.819, required 5, BAYES_44 -0.00,
]         DATE_IN_PAST_03_06 0.42, HTML_MESSAGE 0.10, HTML_RELAYING_FRAME 1.73,
]         MIME_BASE64_TEXT 1.01, MIME_HTML_NO_CHARSET 0.56)
] X-MailScanner-SpamScore: sss
] Return-Path: <[snip]@rochester.rr.com>
] X-Keywords:                  
] X-UID: 6015
] Status: RO
] X-Status: 
] 
] 
] 
] --podulmk
] Content-Type: text/html
] Content-Transfer-Encoding: quoted-printable
] 
] <HTML>ALERT!<BR><BR>This e-mail, in its original form, contained one or more attached files that were infected with a virus, worm, or other type of security threat. This e-mail was sent from a Road Runner IP address. As part of our continuing initiative to stop the spread of malicious viruses, Road Runner scans all outbound e-mail attachments. If a virus, worm, or other security threat is found, Road Runner cleans or deletes the infected attachments as necessary, but continues to send the original message content to the recipient. Further information on this initiative can be found at http://help.rr.com/faqs/e_mgsp.html.<BR><BR>Please be advised that Road Runner does not contact the original sender of the e-mail as part of the scanning process. Road Runner recommends that if the sender is known to you, you contact them directly and advise them of their issue. If you do not know the sender, we advise you to forward this message in its entirety (including full headers) to the !
] Road Runner Abuse Department, at abuse@rr.com.
] 
] 
] <HEAD></HEAD>
] <BODY>
] <iframe src=3D"cid:steausacbyko" height=3D0 width=3D0></iframe>
] <BR><BR>Hi.
] <BR>Message from rocketmail.com
] <BR><BR>I'm sorry to have to inform you that =
] the message returned below could not be delivered =
] to one or more destinations.<BR>
] <BR><BR><BR>Undeliverable to <B>cgbnuug@rocketmail.com</B>
] <BR><BR><BR>Message follows:<BR><BR><BR><BR>
] </BODY></HTML>
] 
] --podulmk
] Content-Type: text/plain;
] 	name="DELETED0.TXT"
] Content-Transfer-Encoding: base64
] Content-Id: <steausacbyko>
[snip]


[ >From [snip]@rochester.rr.com  Sun Sep 19 21:16:12 2004
[ Received: from loki.chebucto.ns.Ca ([192.75.95.97]:51592 "EHLO
[         loki.chebucto.ns.ca") by halifax.chebucto.ns.ca with ESMTP
[         id S15048AbUITAP1 (ORCPT <rfc822;af380@chebucto.ns.ca>);
[         Sun, 19 Sep 2004 21:15:27 -0300
[ Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]:52898 "EHLO
[         ms-smtp-01.nyroc.rr.com") by loki.chebucto.ns.ca with ESMTP
[         id <S4251096AbUITALW>; Sun, 19 Sep 2004 21:11:22 -0300
[ Received: from asuuch (roc-66-66-218-92.rochester.rr.com [66.66.218.92])
[         by ms-smtp-01.nyroc.rr.com (8.12.10/8.12.10) with SMTP id i8JIeQZw000840;
[         Sun, 19 Sep 2004 14:40:26 -0400 (EDT)
[ Date:   Sun, 19 Sep 2004 14:40:26 -0400 (EDT)
[ Message-Id: <200409191840.i8JIeQZw000840@ms-smtp-01.nyroc.rr.com>
[ FROM:   "Network Security Department" <>
[ TO:     "User" <user_tfaqikjs@newsletters.com>
[ SUBJECT: Current Net Security Update
[ X-ID:   842996926937
[ Mime-Version: 1.0
[ Content-Type: multipart/mixed; boundary="qfxbaibs"
[ X-Virus-Scanned: Symantec AntiVirus Scan Engine
[ X-Virus-Scan-Result: Repaired 34162 W32.Swen.A@mm
[ X-MailScanner: Clean
[ X-Is-Spam: not spam, SpamAssassin (score=2.138, required 5, BAYES_20 -1.43,
[         DATE_IN_PAST_03_06 0.42, FROM_NO_USER 2.39, HTML_70_80 0.10,
[         HTML_MESSAGE 0.10, MIME_HTML_NO_CHARSET 0.56)
[ X-MailScanner-SpamScore: ss
[ Return-Path: <[snip]@rochester.rr.com>
[ X-Keywords:                  
[ X-UID: 6016
[ Status: RO
[ X-Status: 
[ 
[ 
[ 
[ --qfxbaibs
[ Content-Type: multipart/related; boundary="ducrpuwnnsbcl";
[ 	type="multipart/alternative"
[ 
[ --ducrpuwnnsbcl
[ Content-Type: multipart/alternative; boundary="iayaepmvjifwr"
[ 
[ --iayaepmvjifwr
[ Content-Type: text/plain
[ Content-Transfer-Encoding: quoted-printable
[ 
[ ALERT!
[ 
[ This e-mail, in its original form, contained one or more attached files that were infected with a virus, worm, or other type of security threat. This e-mail was sent from a Road Runner IP address. As part of our continuing initiative to stop the spread of malicious viruses, Road Runner scans all outbound e-mail attachments. If a virus, worm, or other security threat is found, Road Runner cleans or deletes the infected attachments as necessary, but continues to send the original message content to the recipient. Further information on this initiative can be found at http://help.rr.com/faqs/e_mgsp.html.
[ Please be advised that Road Runner does not contact the original sender of the e-mail as part of the scanning process. Road Runner recommends that if the sender is known to you, you contact them directly and advise them of their issue. If you do not know the sender, we advise you to forward this message in its entirety (including full headers) to the Road Runner Abuse Department, at abuse@rr.com.
[ 
[ MS User
[ 
[ this is the latest version of security update, the
[snip]

-- 
Norman De Forest          http://www.chebucto.ns.ca/~af380/Profile.html
af380@chebucto.ns.ca           [=||=]          (A Speech Friendly Site)
"O'Reilly is to a system administrator as a shoulder length latex glove
is to a veterinarian."   -- Peter da Silva in the scary devil monastery

In article <Pine.GSO.3.95.iB1.0.1041003043946.25914B-100000@halifax.chebucto.ns.ca>,
Norman L. DeForest <af380@chebucto.ns.ca> wrote:
>
>On 2 Oct 2004, John F Hall wrote:

>> Eh?  I'm talking of email *to* me, from people I don't know, and with a
>> forged from address naming other people I don't know, originated by a
>> virus, and containing a virus - and that some MTA along the way has
>> spotted contains a virus, and has "accepted, stripped, and sent on to
>> me".   I get an email saying that complete.stranger@unknown.isp has sent
>> me a virus that's been removed by the MTA's virus detector and they
>> think I should know.  (I've tried to find an example but can't find one
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> at the moment.)  I'm at a loss to understand why *anyone* should think
>  ^^^^^^^^^^^^^^^
>> I could be interested.
>
>Like these copies of Swen?
>
>] >From [snip]@rochester.rr.com  Sun Sep 19 19:56:19 2004
>] Received: from lich.chebucto.ns.Ca ([192.75.95.79]:41801 "EHLO
>]         lich.chebucto.ns.ca") by halifax.chebucto.ns.ca with ESMTP
>]         id S13828AbUISWx4 (ORCPT <rfc822;af380@chebucto.ns.ca>);
>]         Sun, 19 Sep 2004 19:53:56 -0300
>] Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]:44747 "EHLO
>]         ms-smtp-01.nyroc.rr.com") by lich.chebucto.ns.ca with ESMTP
>]         id <S414343AbUISWxr>; Sun, 19 Sep 2004 19:53:47 -0300
>] Received: from ythu (roc-66-66-218-92.rochester.rr.com [66.66.218.92])
>]         by ms-smtp-01.nyroc.rr.com (8.12.10/8.12.10) with SMTP id i8JIgkZw002910;
>]         Sun, 19 Sep 2004 14:42:46 -0400 (EDT)
>] Date:   Sun, 19 Sep 2004 14:42:46 -0400 (EDT)
>] Message-Id: <200409191842.i8JIgkZw002910@ms-smtp-01.nyroc.rr.com>
>] FROM:   "Microsoft Internet Email Delivery System" 
>]         <mailerroutine@rocketmail.com>
>] TO:     "internet recipient" <user@yourserver.com>
>] SUBJECT: Report
>] X-ID:   842996926937
>] Mime-Version: 1.0
>] Content-Type: multipart/alternative;
>]         boundary="podulmk"
>] X-Virus-Scanned: Symantec AntiVirus Scan Engine
>] X-Virus-Scan-Result: Repaired 34162 W32.Swen.A@mm
>] X-MailScanner: Clean
>] X-Is-Spam: not spam, SpamAssassin (score=3.819, required 5, BAYES_44 -0.00,
>]         DATE_IN_PAST_03_06 0.42, HTML_MESSAGE 0.10, HTML_RELAYING_FRAME 1.73,
>]         MIME_BASE64_TEXT 1.01, MIME_HTML_NO_CHARSET 0.56)
>] X-MailScanner-SpamScore: sss
>] Return-Path: <[snip]@rochester.rr.com>
>] X-Keywords:                  
>] X-UID: 6015
>] Status: RO
>] X-Status: 

Quite.

  From xxxxx@rochester.rr.com  Tue Dec  2 23:12:25 2003
  Return-Path: <xxxxx@rochester.rr.com>
  Received: from lon1-punt3-1.mail.demon.net
       (lon1-punt3-1.mail.demon.net [194.217.242.164]) by
       avondale.demon.co.uk (8.12.9/8.12.9) with SMTP id hB2N3emh000336
       for <jfh@avondale.demon.co.uk>; Tue, 2 Dec 2003 23:12:21 GMT
  Received: from punt-3.mail.demon.net by mailstore
	for jfh@avondale.demon.co.uk id 1ARAiq-0005yX-5O;
	Tue, 02 Dec 2003 14:15:24 +0000
  Received: from [24.24.2.55] (helo=ms-smtp-01.nyroc.rr.com)
	by punt-3.mail.demon.net with esmtp id 1ARAiq-0005yX-5O
	for jfh@avondale.demon.co.uk; Tue, 02 Dec 2003 13:37:48 +0000
  Received: from npad (roc-66-67-171-77.rochester.rr.com [66.67.171.77])
	by ms-smtp-01.nyroc.rr.com (8.12.10/8.12.10) with SMTP id
	hB2DUvQE010230; Tue, 2 Dec 2003 08:30:57 -0500 (EST)
  Date: Tue, 2 Dec 2003 08:30:57 -0500 (EST)
  Message-Id: <200312021330.hB2DUvQE010230@ms-smtp-01.nyroc.rr.com>
  X-Virus-Scanned: Symantec AntiVirus Scan Engine
  X-Virus-Scan-Result: Repaired 34162 W32.Swen.A@mm

There's one :-).  "Repaired" - yuck!

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

In <cjfdp8$sa0$1@avondale.demon.co.uk>, on 09/29/2004
   at 10:42 PM, jfh@avondale.demon.co.uk (John F Hall) said:

>But we're discussing viruses,

No we aren't. We're discussing messages that have triggered
virus-detection software. The current state of the art is such that
you are pretty much guarantied that there will be false positives.

>with almost certainly false sender addresses.

No.

-- 
     Shmuel (Seymour J.) Metz, truly insane Spews puppet
     <http://patriot.net/~shmuel>

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail. Reply to 
domain Patriot dot net user shmuel+news to contact me.  Do not 
reply to spamtrap@library.lspace.org

In <cjffi1$so6$1@avondale.demon.co.uk>, on 09/29/2004
   at 11:13 PM, jfh@avondale.demon.co.uk (John F Hall) said:

>What "legitimate sender"?  We're discussing viruses with almost
>certainly false sender addresses.

No. We're discussing messages that triggered anti-virus software. We
know that not all of them actually are viruses, and we do *not* know
that the viruses have false sender addresses.

>And if *none* of them are misconfigured?

Then the sender address is correct.

>You are still stubbornly niggling over details

The Devil is in the details.

>and ignoring the main points.

If the details are wrong then there is no basis for the points.

>Once you *know* that an email is a virus, 

Once I inherit Bill Gates's stock in micro$oft. We are discussing
current and foreseeable software, not some fantasy. We don't know that
the message is a virus or a worm.

>once you *know* that its sender address is false, 

We don't know that.

>what service is given to *anyone* by instructing the previous MTA 
>to send a DSN? 

What service is offered by deliberately asking questions with
assumptions contrary to fact?

>Tut-tutting that it shouldn't have offered it to you isn't fruitful 

Pretending that our anti-virus software is infalible isn't fruitful.

>And you also ignored my suggestion that the major upswing in viruses
>means that it is desirable for virus detection to be performed as
>early as possible,

No. That suggestion does not justify discarding legitimate messages
without a warning.

-- 
     Shmuel (Seymour J.) Metz, truly insane Spews puppet
     <http://patriot.net/~shmuel>

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail. Reply to 
domain Patriot dot net user shmuel+news to contact me.  Do not 
reply to spamtrap@library.lspace.org

In <cji1ht$ehi$1@avondale.demon.co.uk>, on 09/30/2004
   at 10:32 PM, jfh@avondale.demon.co.uk (John F Hall) said:

>You're wittering.  This has nothing to do with Demon.

You're evading the point. It has everything to do with Demon.

>But that's not the point.  Viruses do exist - in large numbers. 
>They are being offered.  And *every* MTA that rejects it (other than
>the MSA[1]) causes a DSN to go to an innocent.

No.

-- 
     Shmuel (Seymour J.) Metz, truly insane Spews puppet
     <http://patriot.net/~shmuel>

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail. Reply to 
domain Patriot dot net user shmuel+news to contact me.  Do not 
reply to spamtrap@library.lspace.org

On Mon, 27 Sep 2004, Mark Marcus wrote:
> ...
> AC's approach of sending ALL mail to /dev/null isn't well thought out.
> As others pointed out, bandwidth is used in order to deliver that
> stream to your local /dev/null.  Because the message wasn't bounced
> (i.e. an SMTP error), the spammer never knows that the email address
> is "invalid" ... so he'll continue sending spam, consuming precious
> bandwidth.

If you think that spammers are monitoring their bounces, you are living in the
past - about 2000.  When spammers started with the random "mix and match" of
valid mailbox usernames and valid domains to try to find previously unknown (to
them) mailboxes, all monitoring of bounces or returned errors was abandoned by
them.  This method would inherently cause a high number of returned or bounced
messages due to unused mailbox names generated by it.

On Sun, 3 Oct 2004, Shmuel (Seymour J.) Metz wrote:

> In <cjffi1$so6$1@avondale.demon.co.uk>, on 09/29/2004
>    at 11:13 PM, jfh@avondale.demon.co.uk (John F Hall) said:
> 
> >What "legitimate sender"?  We're discussing viruses with almost
> >certainly false sender addresses.
> 
> No. We're discussing messages that triggered anti-virus software. We
> know that not all of them actually are viruses, and we do *not* know
> that the viruses have false sender addresses.
[snip]

A major percentage of those messages that are identified by anti-virus
software by name as being a virus *known* to forge addresses *will* be
viruses.  Should thousands of people have to risk exposure to them to get
a few legitimate emails through?  You do know that there *are* people
out there who, when faced with a notice that reads "The attachment,
BrittanysTits.scr in this message [From: fuckyou@yahoo.invalid] was
identified as the worm SpamZombieInstaller@mm and has been quarantined.
[hyperlink]Click here[/hyperlink] if you think this is in error to recover
the attchment.", will see only the "BrittanysTits" and click on it in a
hurry, turning their own machine into a spam-and-virus spewer and making
email even less reliable for everyone else.

A legitimate attachment, MyDog.gif is very unlikely to be identified
as an executable unless the ISP is using really brain-dead anti-virus
software -- in which case I wouldn't trust the reliability of their emeil 
system at all.

Most (if not all) attachments identified by antivirus software
*by name* as being a known infectious executable file *will* be
an executable file.  Most false alarms are for JavaScript exploits
and the like.  I doubt if there would be a rash of false alarms
falsely detecting W32.Netsky.I@mm *by name* in random attachments.
Such false alarms can occur but usually with specific software
triggering the false alarms and the vendor of that software will very
likely act quickly to get the anti-virus company to fix their false
alarm and take action to bypass such false alarms (such as encrypting
their attachments, sending URLs for downlaods from their site instead
of sending attachments, etc.).

There is also a chance that the attachment will get deleted anyway by the
recipient's own antivirus software after it is received if they are the
ones using an anti-virus that false alarms on that attachment.  In that
case, the sender may still not get any notice of failure (or an indignant
"You sent me a virus.  Do not ever email me again!" from the intended
recipient).

If someone wants to send an executable file by email, they can precede
it with a message "Immediately following this message will be an email
with the executable file you wanted."  Please let me know when you got
it or let me know if you haven't received it withing the next seven
days."  If they don't hear back or get notified that the message never
arrived, they can resend it (possibly in encrypted form).

I think that there will be less overall harm done if viruses *known* to
forge addresses that are identified by name are just dropped on the floor
*and a big stink is made about it when a poorly-designed antivirus
starts false alarming _by_name_ for those viruses*.

-- 
Norman De Forest          http://www.chebucto.ns.ca/~af380/Profile.html
af380@chebucto.ns.ca           [=||=]          (A Speech Friendly Site)
"O'Reilly is to a system administrator as a shoulder length latex glove
is to a veterinarian."   -- Peter da Silva in the scary devil monastery

In article <Pine.LNX.4.60.0410040529040.106@kd6lvw.ampr.org>,
 "D. Stussy" <kd6lvw@bde-arc.ampr.org> wrote:

> On Mon, 27 Sep 2004, Mark Marcus wrote:
> > ...
> > AC's approach of sending ALL mail to /dev/null isn't well thought out.
> > As others pointed out, bandwidth is used in order to deliver that
> > stream to your local /dev/null.  Because the message wasn't bounced
> > (i.e. an SMTP error), the spammer never knows that the email address
> > is "invalid" ... so he'll continue sending spam, consuming precious
> > bandwidth.
> 
> If you think that spammers are monitoring their bounces, you are living in 
> the
> past - about 2000.  When spammers started with the random "mix and match" of
> valid mailbox usernames and valid domains to try to find previously unknown 
> (to
> them) mailboxes, all monitoring of bounces or returned errors was abandoned 
> by
> them.  This method would inherently cause a high number of returned or 
> bounced
> messages due to unused mailbox names generated by it.

It's not a very useful approach to think of all spammers acting in 
lockstep with the most obvious behavioral changes. They don't. 
DoubleClick, Amazon, Responsys, Digital Impact, OptInBig, and Alan  
Ralsky are all quite different spammers and all deal with their targets 
in different ways. The first 4 probably pay some attention to bounces.

-- 
Now where did I hide that website...

In article <Pine.GSO.3.95.iB1.0.1041004095402.14369A-100000@halifax.chebucto.ns.ca>,
Norman L. DeForest <af380@chebucto.ns.ca> wrote:
>
>On Sun, 3 Oct 2004, Shmuel (Seymour J.) Metz wrote:
>
>> In <cjffi1$so6$1@avondale.demon.co.uk>, on 09/29/2004
>>    at 11:13 PM, jfh@avondale.demon.co.uk (John F Hall) said:
>> 
>> >What "legitimate sender"?  We're discussing viruses with almost
>> >certainly false sender addresses.
>> 
>> No. We're discussing messages that triggered anti-virus software. We
>> know that not all of them actually are viruses, and we do *not* know
>> that the viruses have false sender addresses.
>[snip]
>
>A major percentage of those messages that are identified by anti-virus
>software by name as being a virus *known* to forge addresses *will* be
>viruses.  Should thousands of people have to risk exposure to them to get
>a few legitimate emails through?  

If a virus sends a message with a particular address as the envelope-from
there is a very good chance that the virus will also send a message with
that address in the envelope-to.

People who are using Microsoft's Virus Runtime Environment should be
using up-to-date virus scanners. 

There is no additional risk because people who get bounce will (in general)
also get the virus directly. Futhermore, usually the virus scanner will
block bounces that cantain viruses.

Of course, if you don't want to run any risks, read mail on a secure
operating system. 



-- 
This Monk had first gone wrong when it was [...] cross-connected to a video
recorder that was watching eleven TV channels simultaneously, [...] The video
recorder only had to watch them, of course. It didn't have to believe them all
as well. This is why instruction manuals are so important    -- Douglas Adams

In article <41607294$10$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <cjfdp8$sa0$1@avondale.demon.co.uk>, on 09/29/2004
>   at 10:42 PM, jfh@avondale.demon.co.uk (John F Hall) said:
>
>>But we're discussing viruses,
>
>No we aren't. We're discussing messages that have triggered
>virus-detection software. The current state of the art is such that
>you are pretty much guarantied that there will be false positives.

OK.  Statistics please.

>>with almost certainly false sender addresses.
>
>No.

Statistics please.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

In article <4160752f$11$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <cjffi1$so6$1@avondale.demon.co.uk>, on 09/29/2004
>   at 11:13 PM, jfh@avondale.demon.co.uk (John F Hall) said:

>>And if *none* of them are misconfigured?
>
>Then the sender address is correct.

Non sequitur.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

Bill Cole wrote:
> In article <Pine.LNX.4.60.0410040529040.106@kd6lvw.ampr.org>,
>  "D. Stussy" <kd6lvw@bde-arc.ampr.org> wrote:
> 
> 
>>On Mon, 27 Sep 2004, Mark Marcus wrote:
>>
>>>...
>>>AC's approach of sending ALL mail to /dev/null isn't well thought out.
>>>As others pointed out, bandwidth is used in order to deliver that
>>>stream to your local /dev/null.  Because the message wasn't bounced
>>>(i.e. an SMTP error), the spammer never knows that the email address
>>>is "invalid" ... so he'll continue sending spam, consuming precious
>>>bandwidth.
>>
>>If you think that spammers are monitoring their bounces, you are living in 
>>the
>>past - about 2000.  

    Worse, unless your system carefully checks the return path for
forgeries (like SpamCop does), your bounces contribute to the
spam problem, because the source is probably forged.

				John Nagle

In article <mip3d.5101$gG4.3599@newsread1.news.pas.earthlink.net>,
Alan Connor  <xxxx@yyy.zzz> wrote:

>Same for any major ISP: Their bureaucracies are dumb as bricks
>and slow as molasses in January,

35mph isn't that slow.

Seth

In article <cji1ht$ehi$1@avondale.demon.co.uk>,
John F Hall <jfh@avondale.demon.co.uk> wrote:
>In article <Xns9573D427FC128morelydotespcgamerev@192.168.0.197>,
>Morely 'I drank what?' Dotes <morelydotes@spamblocked.com> wrote:
>>Meanwhile, as our hero sinks slowly in the West, on 29 Sep 2004,
>>jfh@avondale.demon.co.uk (John F Hall) wrote in
>>news:cjfdp8$sa0$1@avondale.demon.co.uk: 

>>Bullshit. A reject is a statement to the immediately-sending server that 
>>the message is undeliverable.
>
>And?

And then it's up to the sending server what it chooses to do.

>We're talking about how your server - for each and every "you" reading
>this - reacts when it is offered an email containg a virus.
>
>It could:

.. . .
>  reject, causing previous MTA to raise a DSN

In the case of a virus, the "previous MTA" is typically the virus
itself running on an infected machine, and it will not send a DSN when
it gets a rejection.

Seth

In article <cjnb82$i0b$1@avondale.demon.co.uk>,
John F Hall <jfh@avondale.demon.co.uk> wrote:

>Eh?  I'm talking of email *to* me, from people I don't know, and with a
>forged from address naming other people I don't know, originated by a
>virus, and containing a virus - and that some MTA along the way has
>spotted contains a virus, and has "accepted, stripped, and sent on to
>me".   I get an email saying that complete.stranger@unknown.isp has sent
>me a virus that's been removed by the MTA's virus detector and they
>think I should know.  (I've tried to find an example but can't find one
>at the moment.)  I'm at a loss to understand why *anyone* should think
>I could be interested.

Were there some early email viruses that infected actual messages?  If
so, you might want the rest of the message.

(It's also possible that some MTA programmers guessed that might
happen, and coded for it rather than for reality.  Guessing at specs
has a long and dishonorable history.)

Seth

sethb@panix.com (Seth Breidbart) writes:
>>Same for any major ISP: Their bureaucracies are dumb as bricks
>>and slow as molasses in January,
>
>35mph isn't that slow.

That was in October, on an unseasonably warm day. *
-- 
* PV   something like badgers--something like lizards--and something
       like corkscrews.

Following myself up, pv+usenet@pobox.com (Paul Vader) writes:
>sethb@panix.com (Seth Breidbart) writes:
>>>Same for any major ISP: Their bureaucracies are dumb as bricks
>>>and slow as molasses in January,
>>
>>35mph isn't that slow.
>
>That was in October, on an unseasonably warm day. *

I was wrong. Serves me right looking at just the first link for "molasses
flood", and going by the cache text in google.

My grandmother used to say "slow as molasses in january" all the time. Is
the molasses flood where it came from? wordorigins.com doesn't have an
entry for it. *
-- 
* PV   something like badgers--something like lizards--and something
       like corkscrews.

In article <dwh8d.4583$JG2.2795@newssvr14.news.prodigy.com>,
John Nagle  <nagle@animats.com> wrote:
>Bill Cole wrote:
>> In article <Pine.LNX.4.60.0410040529040.106@kd6lvw.ampr.org>,

>>>If you think that spammers are monitoring their bounces, you are living in 
>>>the
>>>past - about 2000.  
>
>    Worse, unless your system carefully checks the return path for
>forgeries (like SpamCop does), your bounces contribute to the
>spam problem, because the source is probably forged.

There are two errors there.  First, it misquotes Mr. Cole, who actually
wrote:

] It's not a very useful approach to think of all spammers acting in 
] lockstep with the most obvious behavioral changes. They don't. 
] DoubleClick, Amazon, Responsys, Digital Impact, OptInBig, and Alan  
] Ralsky are all quite different spammers and all deal with their targets 
] in different ways. The first 4 probably pay some attention to bounces.

Mr. Cole seriously understated that point.  In fact it is betneen very
naive and dishonest to claim that all spammers do anything except send
unsolicited bulk email.  Some clearly monitor their bounces, as shown
in some cases by the use of MUAs that generate unique-per-target,
one-time SMTP envelope Mail_From values designed to ease tracking of
bounces.  Many others just as clearly do not montior their bounces,
as shown by their use of forged Mail_From values.

Whether more or fewer spammers monitor bounces today than yesterday
would be difficult to determine and of limited interested.


Second, the claim of "probably forged" is almost certainly unsupported
by any measurements and is merely a chanting of the kooky NANAE liturgy.
Simple inspection of my sample of incoming spam strongly suggests that
most spam does not have Mail_From return addresses that could be called
"forged" by an honest observer.

Perhaps the best proof that the old "probably forged" claim is a
disingenuous, gross overstatement is in your own mailbox.  If most
spam had forged return addresses, then the number of bounces you receive
would be on the order of T*P*B, where T=average spam load of a targeted
mailbox, P=probability that a target address is bogus, and B=fraction
of mailboxes that bounce after the SMTP transaction.

I see at least 10 and perhaps 100 times as many virus/worm bounces as 
spam bounces.  That implies that 90% of forged junk is from viruses.
Since I think viruses generate only about 10% of all spam, I'm forced
to conclude that only a little spam has forged return addresses.

A major source of the old "most spam is forged" canard consists of users
of free providers who don't like the fact that their mail providers
support spammers with drop boxes.  Never mind whether the economics of
providing free mailboxes would permit serious efforts to keep spammer
away, because reasons, motives, and excuses don't change the bald facts.


Vernon Schryver    vjs@rhyolite.com

In message <cjsa2k$mug$1@panix5.panix.com> sethb@panix.com (Seth
Breidbart) wrote:

>Were there some early email viruses that infected actual messages?  If
>so, you might want the rest of the message.

Some of the earlier ones (Melissa?) attached themselves to otherwise
legitimate email.

Prior to that, anyone remember when viruses were viruses and infected
preexisting files (and/or documents -- Word, for example)


-- 
I've given up on sigs. I just couldn't think of anything clever to say.

On Mon, 4 Oct 2004, Philip Homburg wrote:

> In article <Pine.GSO.3.95.iB1.0.1041004095402.14369A-100000@halifax.chebucto.ns.ca>,
> Norman L. DeForest <af380@chebucto.ns.ca> wrote:
> >
> >On Sun, 3 Oct 2004, Shmuel (Seymour J.) Metz wrote:
> >
> >> In <cjffi1$so6$1@avondale.demon.co.uk>, on 09/29/2004
> >>    at 11:13 PM, jfh@avondale.demon.co.uk (John F Hall) said:
> >> 
> >> >What "legitimate sender"?  We're discussing viruses with almost
> >> >certainly false sender addresses.
> >> 
> >> No. We're discussing messages that triggered anti-virus software. We
> >> know that not all of them actually are viruses, and we do *not* know
> >> that the viruses have false sender addresses.
> >[snip]
> >
> >A major percentage of those messages that are identified by anti-virus
> >software by name as being a virus *known* to forge addresses *will* be
> >viruses.  Should thousands of people have to risk exposure to them to get
> >a few legitimate emails through?  
> 
> If a virus sends a message with a particular address as the envelope-from
> there is a very good chance that the virus will also send a message with
> that address in the envelope-to.
> 
> People who are using Microsoft's Virus Runtime Environment should be
> using up-to-date virus scanners. 

"should" is the operative word here.  Unfortunetely it is not "do".

> 
> There is no additional risk because people who get bounce will (in general)
> also get the virus directly. Futhermore, usually the virus scanner will
> block bounces that cantain viruses.

Not necessarily.  The infected system could be in blocklists that are used
by the forgery-victim's ISP to reject email and the addressed recipients 
would never see the viruses sent directly to their address.  Bounces, on
the other hand, could come from systems not blocked by the ISP and could
get through.

> Of course, if you don't want to run any risks, read mail on a secure
> operating system. 

I access pine running on my ISP's Unix system with a terminal emulator.
Unfortunately, not everyone else reads email on a secure system.

-- 
Norman De Forest          http://www.chebucto.ns.ca/~af380/Profile.html
af380@chebucto.ns.ca           [=||=]          (A Speech Friendly Site)
"O'Reilly is to a system administrator as a shoulder length latex glove
is to a veterinarian."   -- Peter da Silva in the scary devil monastery

Norman L. DeForest <af380@chebucto.ns.ca> wrote:
>On Mon, 4 Oct 2004, Philip Homburg wrote:
>> There is no additional risk because people who get bounce will (in general)
>> also get the virus directly. Futhermore, usually the virus scanner will
>> block bounces that cantain viruses.
>
>Not necessarily.  The infected system could be in blocklists that are used
>by the forgery-victim's ISP to reject email and the addressed recipients 
>would never see the viruses sent directly to their address.  Bounces, on
>the other hand, could come from systems not blocked by the ISP and could
>get through.

Would you care to explain that one. We can assume that the
bounce comes from some kind of smarthost. What prevents the virus from
sending through the smarthost directly to the victim?

Of course, bouncing at the receiving site causes all kinds of troubles,
including the one that you described.

But rejecting a virus at the receiving site is quite different from bouncing
it.



-- 
This Monk had first gone wrong when it was [...] cross-connected to a video
recorder that was watching eleven TV channels simultaneously, [...] The video
recorder only had to watch them, of course. It didn't have to believe them all
as well. This is why instruction manuals are so important    -- Douglas Adams

In <cjs6od$g6k$1@avondale.demon.co.uk>, on 10/04/2004
   at 07:02 PM, jfh@avondale.demon.co.uk (John F Hall) said:

>OK.  Statistics please.

Why? What perrcentage of false positives do you consider acceptable
for dropping into /dev/null?

>Statistics please.

Why? It's enough that I've seen them; it doesn't matter how many.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

In <cjs6se$g7d$1@avondale.demon.co.uk>, on 10/04/2004
   at 07:04 PM, jfh@avondale.demon.co.uk (John F Hall) said:

>Non sequitur.

No. Part of being configured properly is validating the address. If
it's unauthenticated then the server is misconfigured.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

On Tue, 05 Oct 2004 07:32:41 +0000, DevilsPGD wrote:

> In message <cjsa2k$mug$1@panix5.panix.com> sethb@panix.com (Seth
> Breidbart) wrote:
> 
>>Were there some early email viruses that infected actual messages?  If
>>so, you might want the rest of the message.
> 
> Some of the earlier ones (Melissa?) attached themselves to otherwise
> legitimate email.
> 
> Prior to that, anyone remember when viruses were viruses and infected
> preexisting files (and/or documents -- Word, for example)

And to get back on the subject: I predict that if (and that's a very big
if) SPF is successful in stopping forgeries, we will again see a rise in
the numvber of smart virusses that somehow attach to real mail.

M4

In article <cjshkt$1kbq$1@calcite.rhyolite.com>,
Vernon Schryver <vjs@calcite.rhyolite.com> wrote:

>Perhaps the best proof that the old "probably forged" claim is a
>disingenuous, gross overstatement is in your own mailbox.  If most
>spam had forged return addresses, then the number of bounces you receive
>would be on the order of T*P*B, where T=average spam load of a targeted
>mailbox, P=probability that a target address is bogus, and B=fraction
>of mailboxes that bounce after the SMTP transaction.

That assumes that forged addresses exist.  I say it's forgery if a
spammer uses an address he's not entitled to (say, in a domain I own)
even if the address doesn't exist (because no addresses in that domain
exist).

>I see at least 10 and perhaps 100 times as many virus/worm bounces as 
>spam bounces.  That implies that 90% of forged junk is from viruses.
>Since I think viruses generate only about 10% of all spam, I'm forced
>to conclude that only a little spam has forged return addresses.

That is, forged _existing_ return addresses.  You're also making the
assumption that spam bouncing and virus bouncing are equally likely,
which may not be true.

Seth

On Thu, 23 Sep 2004 17:27:04 GMT, Alan Connor <zzzzzz@xxx.yyy> wrote:
> 
> 
> On Thu, 23 Sep 2004 15:43:16 GMT, Jonathan de Boyne Pollard
><J.deBoynePollard@Tesco.NET> wrote:
> 
> 
>> OOO> OOOOOOO, OOOO OOOOOOO OOOO OOOOOOOO (OOOO OOOOOOO) OOO
>> OOOOOOO OO OOOO.
>>
>> O> OOO OOOO'O OOO OOO OOOOOOO OOOO OOOOOO O OOO OOOO OOO OOOO
>> O> OOOO "OOOOOOO" OOOOOOO OO OOOOOOO. OOOOOOOOOOOOO OOOOO
>> O> O OOOO OOOOO OOO OOOO OOOOOOO'O OOO OOOOO OOOO'O OOOOOO
>> O> OOOOOOO OOOO, OOOO OOO OOOOOOOOOOO, OOO OO OOOOOOO OOOOO
>> O> OOOOO OOO OOOO OOOOOOOOOO.
>>
>> "OOOOOOOOOOOOO" OO OOO OOOOOOO OOOO OO O OOO-OOOOOOOOO OOOOO
>> OO OOOOOOO OOOOOOOOOO OO OOOOOO OOOOOOO OOOOO OOOOO OOOO OOOO
>> OOOO OOO OOOOOO OOO OOOO OO OOO OOOO (OOO OOOOOO OO OOOO OO
>> _OOO_ OO OOOO OO OOOOOOOOO OOOOO-OO: OOO OOOOOOOOO OOOOOOO:
>> OOO).  OOOOOOO, OOOOOOOOOOOOO OO OOO OOOOOOO _OOOOOOOO_ OO O
>> OOO-OOOOOOOOO OOOOO OO OOOO OOOOOO OO OOO OOOOO OO OOOOOOO
>> OOOOO, OO OO OOOOOOO OOO OOOOOOO OOOO OOOOOOOO OO OOOOOOOOOOOOO
>> OOOOOO OOO OOOOOOOOOOO OOO OOOOOOOOOO OOOOOOO OOOOO OO OOOOO
>> OOOO OOOOOO OO (OOOOOOOO OOOOOOOOOO) OOOOOOOOO.
>>
>><OOO:OOOO://OO.OO.OO/OOOOO/OOOO.OOO>
> 
> How typical of you to change the subject without noting the fact
> on the Subject line.
> 
> Anyone who believes a word that you post is a fool. 
> 
> Here, your objective is to distract people's attention from
> SPF. 
> 
> Perhaps you could explain why I can't find your alleged name
> in any phonebook in Europe, America, or the Commonwealth?
> 
> The only people with your name that I could find don't even
> know what the Usenet is.
> 
> SPF is a *very* good idea.
> 
> Unless you are a spammer.
> 
> http://spf.pobox.com
> 
> AC
> 
> 
> -- 
> Pass-list --> Block-list --> Challenge-Response
> The key to taking control of your mailboxes
> http://tinyurl.com/3c3agp http://tinyurl.com/2t5kp
> http://tinyurl.com/yrfjb

I second the motion.

This is just to remind people what the spammer's sock puppets
here are trying to do.

But they lost on Challenge-Responses and they'll lose on
SPF too.

Guess they'll have to find honest work.

Isn't that a shame?

AC

xxxx@yyy.zzz (The Alan Connor plague) writes:
>On Thu, 23 Sep 2004 17:27:04 GMT, Alan Connor <zzzzzz@xxx.yyy> wrote:
[whatever]

>I second the motion.

You're 'seconding' your own post, moron. Did you forget to put on your
socks this morning?

>This is just to remind people what the spammer's sock puppets
>here are trying to do.

Excuse me?! *
-- 
* PV   something like badgers--something like lizards--and something
       like corkscrews.
--------------------------------------------------------------------
Free ipod? http://www.freeiPods.com/default.aspx?referer=10031125

In
<Pine.GSO.3.95.iB1.0.1041004095402.14369A-100000@halifax.chebucto.ns.ca>,
on 10/04/2004
   at 10:42 AM, "Norman L. DeForest" <af380@chebucto.ns.ca> said:

>A major percentage of those messages that are identified by
>anti-virus software by name as being a virus *known* to forge
>addresses *will* be viruses.  Should thousands of people have to risk
>exposure to them to get a few legitimate emails through?

Should thousands of people be charged $50 each just so that you can
view child pornography and snuff films? What, you say that has nothing
to do with what you wrote? Well, your question has nothing to do with
what I wrote either. I never said that you shouldn't run antivirus
software; what I said was that the software shouldn't be b0rken.

>You do know that there *are* people
>out there who, when faced with a notice that reads "The attachment,

You do know that there are no attachments on SMTP 5xx error message,
don't you?

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

In article <4162f7bd$42$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <cjs6se$g7d$1@avondale.demon.co.uk>, on 10/04/2004
>   at 07:04 PM, jfh@avondale.demon.co.uk (John F Hall) said:
>
>>Non sequitur.
>
>No. Part of being configured properly is validating the address. If
>it's unauthenticated then the server is misconfigured.

You're wittering.  It's the *IP* address that's validated not the
*email* address, not the user's identity).

(Yes, some MSAs provide remote access by user authentication but that is
not the usual situation.)

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

In article <cjsa2k$mug$1@panix5.panix.com>,
Seth Breidbart <sethb@panix.com> wrote:
>In article <cjnb82$i0b$1@avondale.demon.co.uk>,
>John F Hall <jfh@avondale.demon.co.uk> wrote:
>
>>Eh?  I'm talking of email *to* me, from people I don't know, and with a
>>forged from address naming other people I don't know, originated by a
>>virus, and containing a virus - and that some MTA along the way has
>>spotted contains a virus, and has "accepted, stripped, and sent on to
>>me".   I get an email saying that complete.stranger@unknown.isp has sent
>>me a virus that's been removed by the MTA's virus detector and they
>>think I should know.  (I've tried to find an example but can't find one
>>at the moment.)  I'm at a loss to understand why *anyone* should think
>>I could be interested.
>
>Were there some early email viruses that infected actual messages?  If
>so, you might want the rest of the message.
>
>(It's also possible that some MTA programmers guessed that might
>happen, and coded for it rather than for reality.  Guessing at specs
>has a long and dishonorable history.)

We're talking about *now*, not about "early email viruses" - in
particular of the current explosion of trojan-loaded viruses and the
"zombie networks" they are causing.  And whether old-style viruses are
still a significant problem was discussed earlier in the thread.
Perhaps you weren't paying attention at the time.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

In article <41607624$12$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <cji1ht$ehi$1@avondale.demon.co.uk>, on 09/30/2004
>   at 10:32 PM, jfh@avondale.demon.co.uk (John F Hall) said:
>
>>You're wittering.  This has nothing to do with Demon.
>
>You're evading the point. It has everything to do with Demon.

Rubbish.  What I'm saying has nothing to do with Demon.  If you think it
has it shows merely that you're not taking the trouble to read what I
say.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

In article <cjs9p8$mj3$1@panix5.panix.com>,
Seth Breidbart <sethb@panix.com> wrote:
>In article <cji1ht$ehi$1@avondale.demon.co.uk>,
>John F Hall <jfh@avondale.demon.co.uk> wrote:
>>In article <Xns9573D427FC128morelydotespcgamerev@192.168.0.197>,
>>Morely 'I drank what?' Dotes <morelydotes@spamblocked.com> wrote:
>>>Meanwhile, as our hero sinks slowly in the West, on 29 Sep 2004,
>>>jfh@avondale.demon.co.uk (John F Hall) wrote in
>>>news:cjfdp8$sa0$1@avondale.demon.co.uk: 
>
>>>Bullshit. A reject is a statement to the immediately-sending server that 
>>>the message is undeliverable.
>>
>>And?
>
>And then it's up to the sending server what it chooses to do.

Having no idea *why* it was rejected, it will follow the RFCs and send a
DSN to the "mail from" address.

>>We're talking about how your server - for each and every "you" reading
>>this - reacts when it is offered an email containg a virus.
>>
>>It could:
>
>. . .
>>  reject, causing previous MTA to raise a DSN
>
>In the case of a virus, the "previous MTA" is typically the virus
>itself running on an infected machine, and it will not send a DSN when
>it gets a rejection.

What nonsense.  For every virus that applies to exactly *one* of the
MTAs it goes through - there are normally a handful of "Received" lines
on every virus that *my* MTA detects.  (And, no, I *don't* reject them
and cause a DSN to be sent to the mail-from address.)

It would be true of course if what I am advocating were adopted and
*every* MTA checked for viruses.  We are still a long way from that :-(.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

In article <4162f767$41$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <cjs6od$g6k$1@avondale.demon.co.uk>, on 10/04/2004
>   at 07:02 PM, jfh@avondale.demon.co.uk (John F Hall) said:
>
>>OK.  Statistics please.
>
>Why? What perrcentage of false positives do you consider acceptable
>for dropping into /dev/null?
>
>>Statistics please.
>
>Why? It's enough that I've seen them; it doesn't matter how many.

Obviously I don't want *any* false positives.  Equally obviously I
accept that you can't implement any blocking scheme without some risk of
them happening.

The question is whether they occur sufficiently often to invalidate the
use of particular techniques and policies.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

On Thu, 7 Oct 2004, Shmuel (Seymour J.) Metz wrote:

> In
> <Pine.GSO.3.95.iB1.0.1041004095402.14369A-100000@halifax.chebucto.ns.ca>,
> on 10/04/2004
>    at 10:42 AM, "Norman L. DeForest" <af380@chebucto.ns.ca> said:
> 
> >A major percentage of those messages that are identified by
> >anti-virus software by name as being a virus *known* to forge
> >addresses *will* be viruses.  Should thousands of people have to risk
> >exposure to them to get a few legitimate emails through?
> 
> Should thousands of people be charged $50 each just so that you can
> view child pornography and snuff films? What, you say that has nothing
> to do with what you wrote? Well, your question has nothing to do with
> what I wrote either. I never said that you shouldn't run antivirus
> software; what I said was that the software shouldn't be b0rken.

What I wrote is that a ***!!KNOWN!!!*** worm that is !!!**KNOWN**!!! to
forge addresses should be dropped silently.  There is no possible good
that can come from either bouncing or *rejecting* it.  In cases where
there is any doubt about the worm's identity or its propensity to forge
addresses, then I won't argue with you.

However, if you do detect a worm that is known to forge addresses and the
identification is conclusive:

If you reject:
  -- if the worm is sending directly it will ignore the rejection
     so rejecting and dropping do the same thing.
  -- if the worm is sending through a poorly configured smarthost for
     the infected user, it could very easily send a bounce *in full
     infectious form* to the forged sender.
If you bounce, you will be sending to the forgery victim.
If you drop the message in the trash (aka /dev/null) then no harm is done.

> >You do know that there *are* people
> >out there who, when faced with a notice that reads "The attachment,
> 
> You do know that there are no attachments on SMTP 5xx error message,
> don't you?

Yes, but you don't necessarily know what the sending system is going to do
when you reject the message.  It just might send an infectious copy of the
worm to the forged sender.

-- 
Norman De Forest          http://www.chebucto.ns.ca/~af380/Profile.html
af380@chebucto.ns.ca           [=||=]          (A Speech Friendly Site)
"O'Reilly is to a system administrator as a shoulder length latex glove
is to a veterinarian."   -- Peter da Silva in the scary devil monastery

N3S> Feel free to explain why spammers can't simply add SPF records to
N3S> their automated scripts that sign up for hundreds of domain names
N3S> at a time, and which already set up domain records for those
N3S> domains.

MW> They can but they'll have to change those scripts.

Big deal.  It's probably the work of a few minutes.  Given that UBM 
senders are adopting SPF faster than anyone else, it's also a good bet 
that some have done exactly this already.

MW> I suspect at a point, spf MTA modules may give the option of
MW> rejecting SPF records representing more than a configuration defined
MW> number of IPs.

Thus rendering the recommendation to roaming users (given by the SPF FAQ 
itself) entirely useless.

JR> SPF is NOT an anti-spam measure, it's an anti-forgery measure.

And fails dismally at that, too.  The way to address forgeries in 
electronic mail is the same as the way to address forgeries in paper 
mail: signatures.

* Fri 2004-10-08 Jonathan de Boyne Pollard <J.deBoynePollard AT Tesco.NET>
| JR> SPF is NOT an anti-spam measure, it's an anti-forgery measure.
| 
| And fails dismally at that, too.  The way to address forgeries in 
| electronic mail is the same as the way to address forgeries in paper 
| mail: signatures.

I don't think this is fair statement. SPF is anti-forgery measure in
that sense, that the mail must travel through official channels. In
current situation any host can connect to any other host and that's
the problem.

With SPF, the spammer is forced to use his ISP's mail servers, because
trying to send mail directly will face rejection in the receiving
host using SPF.

        Spammer                => Tries to talk SMTP to X
                               <= REJECT; "you must use your ISP's MX"

        Spammer => ISP => .... => X; "Okay, valid route detected"
                                  SPF check succeed.


Now, the ISP can monitor the traffic and see if the spammer sends 10
000 messages in short period of time. This would be noticed and the
spammer could be caught. The ISP could even impose hard limits for
individual hosts how many messages could be send (100 a day) and that
would cut the total count of spam.

I would call that a big improvement and not a failure.

Jari

jfh@avondale.demon.co.uk (John F Hall) wrote in news:ck4eia$mul$1
@avondale.demon.co.uk:

> What nonsense.  For every virus that applies to exactly *one* of the
> MTAs it goes through - there are normally a handful of "Received" lines
> on every virus that *my* MTA detects.  (And, no, I *don't* reject them
> and cause a DSN to be sent to the mail-from address.)

You continue to argue from the solopsistic position that Demon is the norm; 
it is not.

-- 
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
To the spammers, my motto: FABRICATI DIEM, PVNC.

"Norman L. DeForest" <af380@chebucto.ns.ca> wrote in
news:Pine.GSO.3.95.iB1.0.1041007220739.24766A-100000@halifax.chebucto.ns.ca
: 

> If you reject:
>   -- if the worm is sending directly it will ignore the rejection
>      so rejecting and dropping do the same thing.

False to fact.  Rejecting prevents use of the amount of bandwidth required
to accept and then drop. 

>   -- if the worm is sending through a poorly configured smarthost for
>      the infected user, it could very easily send a bounce *in full
>      infectious form* to the forged sender.

Frankly, that's not the problem of the admin at the target end of the
worm.  Furthermore, when an ISP constantly sends worms, the proper
response is to firewall them out - SWIP.NET for example (which is still
sending me worm attempts approximately every 30 minutes, according to my
logs). 

> If you bounce, you will be sending to the forgery victim.

Always true, and accurate.

> If you drop the message in the trash (aka /dev/null) then no harm is
> done. 

Harm is done to *my* costs if I accept and drop, vs. reject a known worm 
source.

-- 
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
To the spammers, my motto: FABRICATI DIEM, PVNC.

jfh@avondale.demon.co.uk (John F Hall) wrote in news:ck4cf3$m2v$1
@avondale.demon.co.uk:

> In article <4162f7bd$42$fuzhry+tra$mr2ice@news.patriot.net>,
> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>>In <cjs6se$g7d$1@avondale.demon.co.uk>, on 10/04/2004
>>   at 07:04 PM, jfh@avondale.demon.co.uk (John F Hall) said:
>>
>>>Non sequitur.
>>
>>No. Part of being configured properly is validating the address. If
>>it's unauthenticated then the server is misconfigured.
> 
> You're wittering.  It's the *IP* address that's validated not the
> *email* address, not the user's identity).
> 
> (Yes, some MSAs provide remote access by user authentication but that is
> not the usual situation.)

Even the latest version of M$ Exchange authenticate by domain login. Come 
on, John, get with the 21st Century, will you?

This thread seems to have drifted off into Faerie.


-- 
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
To the spammers, my motto: FABRICATI DIEM, PVNC.

On 8 Oct 2004, The Open Sourceror's Apprentice wrote:

> "Norman L. DeForest" <af380@chebucto.ns.ca> wrote in
> news:Pine.GSO.3.95.iB1.0.1041007220739.24766A-100000@halifax.chebucto.ns.ca
> : 
> 
> > If you reject:
> >   -- if the worm is sending directly it will ignore the rejection
> >      so rejecting and dropping do the same thing.
> 
> False to fact.  Rejecting prevents use of the amount of bandwidth required
> to accept and then drop. 

I was writing about the situation where you *know* it is a worm that
forges addresses. That pretty well implies that rejection is at the end of
the DATA portion of the SMTP transaction otherwise your antivirus software
couldn't have scanned the body of the message to detect the worm.

> 
> >   -- if the worm is sending through a poorly configured smarthost for
> >      the infected user, it could very easily send a bounce *in full
> >      infectious form* to the forged sender.
> 
> Frankly, that's not the problem of the admin at the target end of the
> worm.  Furthermore, when an ISP constantly sends worms, the proper
> response is to firewall them out - SWIP.NET for example (which is still
> sending me worm attempts approximately every 30 minutes, according to my
> logs). 
> 
> > If you bounce, you will be sending to the forgery victim.
> 
> Always true, and accurate.
> 
> > If you drop the message in the trash (aka /dev/null) then no harm is
> > done. 
> 
> Harm is done to *my* costs if I accept and drop, vs. reject a known worm 
> source.

Rejecting a known worm *source* is not what I was writing about but
rejecting *a known worm* -- which can only be done after the DATA stage
because the virus scanner would need to scan the message body in order to
identify the worm -- so a rejection and a discard in that situation would
take the same amount of your resources.

-- 
Norman De Forest          http://www.chebucto.ns.ca/~af380/Profile.html
af380@chebucto.ns.ca           [=||=]          (A Speech Friendly Site)
"O'Reilly is to a system administrator as a shoulder length latex glove
is to a veterinarian."   -- Peter da Silva in the scary devil monastery

"Norman L. DeForest" <af380@chebucto.ns.ca> wrote in
news:Pine.GSO.3.95.iB1.0.1041008123733.4972A-100000@halifax.chebucto.ns.ca:

> On 8 Oct 2004, The Open Sourceror's Apprentice wrote:
> 
>> "Norman L. DeForest" <af380@chebucto.ns.ca> wrote in
>> news:Pine.GSO.3.95.iB1.0.1041007220739.24766A-100000@halifax.chebucto.ns
>> .ca:
>> 
>> > If you reject:
>> >   -- if the worm is sending directly it will ignore the rejection
>> >      so rejecting and dropping do the same thing.
>> 
>> False to fact.  Rejecting prevents use of the amount of bandwidth
>> required to accept and then drop. 
> 
> I was writing about the situation where you *know* it is a worm that
> forges addresses. That pretty well implies that rejection is at the end
> of the DATA portion of the SMTP transaction otherwise your antivirus
> software couldn't have scanned the body of the message to detect the
> worm. 

If it's coming from SWIP.NET, I know that for certain.  I block all email
from SWIP.NET as a consequence. 

You have a problem with that?

-- 
Tired of spam in your mailbox?
Come to http://www.spamblocked.com
Who is Brad Jesness? http://www.wilhelp.com/bj_faq/
To the spammers, my motto: FABRICATI DIEM, PVNC.

In article <Xns957C532ED8F79MorelyDotesspamblock@216.99.211.247>,
The Open Sourceror's Apprentice <spam@uce.gov> wrote:
>jfh@avondale.demon.co.uk (John F Hall) wrote in news:ck4eia$mul$1
>@avondale.demon.co.uk:
>
>> What nonsense.  For every virus that applies to exactly *one* of the
>> MTAs it goes through - there are normally a handful of "Received" lines
>> on every virus that *my* MTA detects.  (And, no, I *don't* reject them
>> and cause a DSN to be sent to the mail-from address.)
>
>You continue to argue from the solopsistic position that Demon is the
>norm; it is not.

  Received: from lon1-punt3-1.mail.demon.net
	(lon1-punt3-1.mail.demon.net +[194.217.242.164]) by
	avondale.demon.co.uk (8.12.11/8.12.9) with SMTP id
	i8CHNPPP000958 for <jfh@avondale.demon.co.uk>; Sun, 12 Sep 2004
	18:27:43 +0100
  Received: from punt-3.mail.demon.net by mailstore
        for jfh@avondale.demon.co.uk id 1C6OaG-0002TF-78;
        Sun, 12 Sep 2004 07:15:36 +0000
  Received: from [194.217.242.71] (helo=anchor-hub.mail.demon.net)
	by punt-3.mail.demon.net with esmtp id 1C6OaG-0002TF-78 for
	jfh@avondale.demon.co.uk; Sun, 12 Sep 2004 07:15:36 +0000
  Received: from [202.224.159.140] (helo=smaster3.hi-ho.ne.jp)
	by anchor-hub.mail.demon.net with esmtp id 1C6OaF-00022g-09 for
	jfh@avondale.demon.co.uk; Sun, 12 Sep 2004 07:15:36 +0000
  Received: from max.hi-ho.ne.jp (sproxy33 [192.168.125.209])
	by smaster3.hi-ho.ne.jp (hi-ho Mail Server) with ESMTP id
	<0I3X00CB20POJB@smaster3.hi-ho.ne.jp> for
	jfh@avondale.demon.co.uk; Sun, 12 Sep 2004 15:29:48 +0900 (JST)
  Received: from igld (west27-p8.eaccess.hi-ho.ne.jp [218.228.106.9])
	by max.hi-ho.ne.jp     id EOTC34D0; Sun, 12 Sep 2004 15:29:22
	+0900 (JST)
  Date: Sun, 12 Sep 2004 15:29:48 +0900 (JST)
  X-Virus-Detected: W32/Swen.A@mm

It seems to have gone through several MTAs before it reached Demon.

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

In article <Xns957C52F1C75A6MorelyDotesspamblock@216.99.211.247>,
The Open Sourceror's Apprentice <spam@uce.gov> wrote:

>Even the latest version of M$ Exchange authenticate by domain login. Come 
>on, John, get with the 21st Century, will you?
>
>This thread seems to have drifted off into Faerie.

It certainly has if you're proposing that Microsoft's behaviour is a
better source of standards than the RFCs :-).

-- 
John F Hall

The Internet relies on the cooperative use of private resources.
Sending email is a privilege not a right.

On Fri, 08 Oct 2004 03:43:06 +0000, Jonathan de Boyne Pollard wrote:

> JR> SPF is NOT an anti-spam measure, it's an anti-forgery measure.
> 
> And fails dismally at that, too.

I don't agree.

>                                   The way to address forgeries in 
> electronic mail is the same as the way to address forgeries in paper 
> mail: signatures.

If you want to have something that holds up in court, yes. If you want
something to decide to accept or reject mail, no. To slow.

M4
-- 
Redundancy is a great way to introduce more single points of failure.

In article <pan.2004.10.09.17.16.25.810264@remove.this.part.rtij.nl>,
Martijn Lievaart  <m@remove.this.part.rtij.nl> wrote:

>> JR> SPF is NOT an anti-spam measure, it's an anti-forgery measure.
>> 
>> And fails dismally at that, too.
>
>I don't agree.

If that is an engineering judgement instead of a religous or other
non-rational statement, then your SMTP server must be using SPF to
reject a significant part of the forged mail that it receives.  How
much mail is your SMTP server using SPF to reject?


>>                                   The way to address forgeries in 
>> electronic mail is the same as the way to address forgeries in paper 
>> mail: signatures.
>
>If you want to have something that holds up in court, yes. If you want
>something to decide to accept or reject mail, no. To slow.

There are few reasons for an MTA or MUA to reject forged mail except
to avoid various kinds of spam.  It is silly to base a spam defense
on whether mail is forged.  Forgery is not a required aspect of spam.
In the extremely unlikely event that any forgery detection mechanism
became popular enough to reject significant spam, there would be no
longer by any forged spam.  (See recent reports that SPF RRs are good
spam sign.)

SPF and similar mechanisms are games that sound interesting to some
people only while they are actually played by practically no one.  As
soon as SPF became popular, spammers and viruses would stop forging
and busy SMTP servers would turn off SPF as a waste of time against
spam that rejects significant amounts of legitimate mail.

Speaking of useless wastes of time that are turned off at busy SMTP
servers run by people with clues, SPF is like IDENT/TAP, except that
SPF is even more obviously useless....I'd not noticed the many parallels
between SPF/RMX/etc and IDENT/TAP:

  - lots of screaming and shouting about who invented the idea first
     and which minor variation is more wonderful.

  - depends on the bad guys not changing their behavior.

  - depends on everyone else changing their computers to publish new
      information.

  - basic protocol vulnerable to attacks by bad guys (SPF/RMX/etc.
      are not quite as wide-open as IDENT/TAP)

  - eventually even the fans get bored and go on to the next panacea.
      (Well, this has not yet happened with SPF/RMX/etc., but it will.)


Vernon Schryver    vjs@rhyolite.com

In <ck4cf3$m2v$1@avondale.demon.co.uk>, on 10/07/2004
   at 09:29 PM, jfh@avondale.demon.co.uk (John F Hall) said:

>You're wittering.

No.

>It's the *IP* address that's validated not the
>*email* address, not the user's identity).

Then you're talking about a relay, and it should be blocked. A
properly configured mail server checks the user's identity.

-- 
     Shmuel (Seymour J.) Metz, truly insane Spews puppet
     <http://patriot.net/~shmuel>

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail. Reply to 
domain Patriot dot net user shmuel+news to contact me.  Do not 
reply to spamtrap@library.lspace.org

On Sat, 09 Oct 2004 11:41:04 -0600, Vernon Schryver wrote:

> In article <pan.2004.10.09.17.16.25.810264@remove.this.part.rtij.nl>,
> Martijn Lievaart  <m@remove.this.part.rtij.nl> wrote:
> 
>>> JR> SPF is NOT an anti-spam measure, it's an anti-forgery measure.
>>> 
>>> And fails dismally at that, too.
>>
>>I don't agree.
> 
> If that is an engineering judgement instead of a religous or other
> non-rational statement, then your SMTP server must be using SPF to
> reject a significant part of the forged mail that it receives.  How
> much mail is your SMTP server using SPF to reject?

None. I haven't gotten around to implementing SPF on the receiving
end yet. But would you care to first back up your statement that it fails
dismally? It fails dismally to stop spam, yes.

>>>                                   The way to address forgeries in 
>>> electronic mail is the same as the way to address forgeries in paper 
>>> mail: signatures.
>>
>>If you want to have something that holds up in court, yes. If you want
>>something to decide to accept or reject mail, no. To slow.
> 
> There are few reasons for an MTA or MUA to reject forged mail except
> to avoid various kinds of spam.  It is silly to base a spam defense
> on whether mail is forged.  Forgery is not a required aspect of spam.
> In the extremely unlikely event that any forgery detection mechanism
> became popular enough to reject significant spam, there would be no
> longer by any forged spam.  (See recent reports that SPF RRs are good
> spam sign.)

No disagreement here. However you sidestepped the original point. If you
want to address forgeries as a way to reject mail, digital signatures are
useless.

Note that I said nowhere that rejecting forgeries is a good thing. I think
it is on general principle, as I think it can make filtering spam more
effective. But whether this is true still has to be shown.

Also note that I did not say that SPF is the answer here, only that
digital signatures are an even worse idea in this context.

> SPF and similar mechanisms are games that sound interesting to some
> people only while they are actually played by practically no one.  As
> soon as SPF became popular, spammers and viruses would stop forging
> and busy SMTP servers would turn off SPF as a waste of time against
> spam that rejects significant amounts of legitimate mail.

That would be a win in my book, although a small one. 

> Speaking of useless wastes of time that are turned off at busy SMTP
> servers run by people with clues, SPF is like IDENT/TAP, except that
> SPF is even more obviously useless....I'd not noticed the many parallels
> between SPF/RMX/etc and IDENT/TAP:

Nice parallel! I think this parallel has a nice side effect. People who
are enthousiastic about SPF but don't know the problems with ident are
easier to dismiss as clueless.

>   - lots of screaming and shouting about who invented the idea first
>      and which minor variation is more wonderful.

I did not know ident had "lot's of screaming". Interesting, you have a
pointer?

>   - depends on the bad guys not changing their behavior.

Yes, but there is a slight difference. With ident you only have an IP,
with SPF you have an IP and a domain. If you know one is coupled with the
other you can do more effective whitelisting. I still have to think out
how to do it in practice though, I'm not completely convinced it can or
cannot be done.

>   - depends on everyone else changing their computers to publish new
>       information.

Yes, absolutely.

>   - basic protocol vulnerable to attacks by bad guys (SPF/RMX/etc.
>       are not quite as wide-open as IDENT/TAP)

I don't see this one at all.

>   - eventually even the fans get bored and go on to the next panacea.
>       (Well, this has not yet happened with SPF/RMX/etc., but it will.)

For those that see it as a panacea, yes absolutely. Others try to judge
the ideas on their merits and the jury is still out on this one.

M4
-- 
Redundancy is a great way to introduce more single points of failure.

On Sun, 10 Oct 2004 14:11:08 +0200, Martijn Lievaart wrote:

>>   - basic protocol vulnerable to attacks by bad guys (SPF/RMX/etc.
>>       are not quite as wide-open as IDENT/TAP)
> 
> I don't see this one at all.

(Except the MS resolver is absolutely vulnerable to SPF-spoofing attacks,
for other resolvers ti should be pretty difficult to spoof SPF).

M4
-- 
Redundancy is a great way to introduce more single points of failure.

In article <pan.2004.10.10.12.11.07.832767@remove.this.part.rtij.nl>,
Martijn Lievaart  <m@remove.this.part.rtij.nl> wrote:

>>>> JR> SPF is NOT an anti-spam measure, it's an anti-forgery measure.
>>>> 
>>>> And fails dismally at that, too.
>>>
>>>I don't agree.
>> 
>> If that is an engineering judgement instead of a religous or other
>> non-rational statement, then your SMTP server must be using SPF to
>> reject a significant part of the forged mail that it receives.  How
>> much mail is your SMTP server using SPF to reject?
>
>None. I haven't gotten around to implementing SPF on the receiving
>end yet.

If SPF were new and had just appeared, tentative support for it
might be reasonable, but SPF has been around for more than a year.
Anyone who supports SPF but has not deployed it locally is either
some kind poseur or lacks standing to have an opinion.



>         But would you care to first back up your statement that it fails
>dismally? It fails dismally to stop spam, yes.

Please check who said what in this thread.  The words above "fails
dismally" were not mine.  However, since you ask, please read what I
have often written.  SPF fails dismally as an anti-forgery measure,
because if it were deployed, it would detect as "forged" a lot of
legitimate mail such as from roaming users.  It cannot detect much of
any truly forged mail unless it is widely deployed, but because of its
many practical problems and lack of effect on spam, it will never be
deployed.  If you are designing for the world as SPF fans wish it were,
then SPF is great; it only fails dismally in the real world.


>> There are few reasons for an MTA or MUA to reject forged mail except
>> to avoid various kinds of spam. 

>No disagreement here. However you sidestepped the original point. If you
>want to address forgeries as a way to reject mail, digital signatures are
>useless.

On the contrary, your raising the fact that digital signatures are
useless as a spam defense was a red herring.  I was combating that
irrelevancy by showing that it is irrelevant.


>Note that I said nowhere that rejecting forgeries is a good thing. I think
>it is on general principle, as I think it can make filtering spam more
>effective. But whether this is true still has to be shown.

Indeed, that is an untested and I think obviously superficial and false 
assumption.


>Also note that I did not say that SPF is the answer here, only that
>digital signatures are an even worse idea in this context.

Yes, but that's a red herring.  No one in this thread suggested using
signatures for detecting forged spam.  The other person's point was
that in the real world situations where forgery matters, SPF is quite
wrong (e.g. not end-to-end) and that digital signatures are the only
mechanisms that come close to working.  I'm not endorsing digital
signatures, but their many real world problems are irrelevant in this
thread.


>> Speaking of useless wastes of time that are turned off at busy SMTP
>> servers run by people with clues, SPF is like IDENT/TAP, except that
>> SPF is even more obviously useless....I'd not noticed the many parallels
>> between SPF/RMX/etc and IDENT/TAP:
>
>Nice parallel! I think this parallel has a nice side effect. People who
>are enthousiastic about SPF but don't know the problems with ident are
>easier to dismiss as clueless.

I do not agree with that.  SPF enthusiasts are obviously clue-resistant
in their own right.  I don't know of any surviving IDENT enthusiasts.


>>   - lots of screaming and shouting about who invented the idea first
>>      and which minor variation is more wonderful.
>
>I did not know ident had "lot's of screaming". Interesting, you have a
>pointer?

Look in the main IETF mailing lists about 12 years ago to find
D.J.Burnstein's seemingly endless and I thought less than honest claims
about how he was ROBBED AND CHEATED OUT OF THE CREDIT FOR TAP AND THAT
IDENT IS INCOMPATIBLE AND FUNDAMENTALLY WRONG AND IT'S ALL A CONSPIRACY
IN THE IETF HIERARCHY AND IF THERE IS ANY JUSTICE THE IDENT RFC WON'T
BE ADVANCED AND A PORT NUMBER WON'T BE ASSIGNED!!!  See
http://free.vlsm.org/v01/internet/ietf/00/0016.txt for Burnstein's
side, but don't take anything he says as true without checking.  I
couldn't find the detailed counterstatements from the IETF bigshots.


>>   - depends on the bad guys not changing their behavior.
>
>Yes, but there is a slight difference. With ident you only have an IP,
>with SPF you have an IP and a domain. If you know one is coupled with the
>other you can do more effective whitelisting. I still have to think out
>how to do it in practice though, I'm not completely convinced it can or
>cannot be done.

There are more significant differences in the TAP/IDENT versus
SPF/RMX/etc mechanisms than whether domain names are involved. 
My point was that their usefulness is based on the kooky assumption
that your adversaries will cooperate by not changing tactics.


>>   - depends on everyone else changing their computers to publish new
>>       information.
>
>Yes, absolutely.
>
>>   - basic protocol vulnerable to attacks by bad guys (SPF/RMX/etc.
>>       are not quite as wide-open as IDENT/TAP)
>
>I don't see this one at all.

IDENT depends on easily forged and inserted UDP/IP packets.  SPF/RMX/etc
also depends on UDP/IP packets, somewhat more difficult to forge and
insert...or were you going to wait to decide whether SPF/RMX/etc is
useful until after DNS-SEC is deployed?


>>   - eventually even the fans get bored and go on to the next panacea.
>>       (Well, this has not yet happened with SPF/RMX/etc., but it will.)
>
>For those that see it as a panacea, yes absolutely. Others try to judge
>the ideas on their merits and the jury is still out on this one.

Anyone whose brain is not so open that it falls out looked at the idea
of SPF/RMX/etc many years ago and decide it wasn't worth the effort.
For example, see
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00658.html


Vernon Schryver    vjs@rhyolite.com

>There are more significant differences in the TAP/IDENT versus
>SPF/RMX/etc mechanisms than whether domain names are involved.
>My point was that their usefulness is based on the kooky assumption
>that your adversaries will cooperate by not changing tactics.

I thought one of the biggest problems with SPF was that spammers were 
adopting it faster than real companies. 

On Sun, 10 Oct 2004 08:52:42 -0600, Vernon Schryver wrote:

> Please check who said what in this thread.  The words above "fails
> dismally" were not mine.  However, since you ask, please read what I

I'm sorry. My bad.

> have often written.  SPF fails dismally as an anti-forgery measure,
> because if it were deployed, it would detect as "forged" a lot of
> legitimate mail such as from roaming users.  It cannot detect much of

Roaming users are a problem, not just for SPF. A problem which is
trivially solved btw. Forwarded mail is a much bigger problem.

> any truly forged mail unless it is widely deployed, but because of its
> many practical problems and lack of effect on spam, it will never be
> deployed.  If you are designing for the world as SPF fans wish it were,
> then SPF is great; it only fails dismally in the real world.

So it fails because it is not employed? I'm not going to split those hairs.

> On the contrary, your raising the fact that digital signatures are
> useless as a spam defense was a red herring.  I was combating that
> irrelevancy by showing that it is irrelevant.

I never said such a thing.

>>Note that I said nowhere that rejecting forgeries is a good thing. I think
>>it is on general principle, as I think it can make filtering spam more
>>effective. But whether this is true still has to be shown.
> 
> Indeed, that is an untested and I think obviously superficial and false 
> assumption.

Lets agree to disagree on that for now.
 
>>Also note that I did not say that SPF is the answer here, only that
>>digital signatures are an even worse idea in this context.
> 
> Yes, but that's a red herring.  No one in this thread suggested using
> signatures for detecting forged spam.  The other person's point was

Then why bring it up?

> http://free.vlsm.org/v01/internet/ietf/00/0016.txt for Burnstein's
> side, but don't take anything he says as true without checking.  I
> couldn't find the detailed counterstatements from the IETF bigshots.

I take NOTHING from djb without checking. Talking about clueresistant!

>>>   - depends on the bad guys not changing their behavior.
>>
>>Yes, but there is a slight difference. With ident you only have an IP,
>>with SPF you have an IP and a domain. If you know one is coupled with the
>>other you can do more effective whitelisting. I still have to think out
>>how to do it in practice though, I'm not completely convinced it can or
>>cannot be done.
> 
> There are more significant differences in the TAP/IDENT versus
> SPF/RMX/etc mechanisms than whether domain names are involved. 
> My point was that their usefulness is based on the kooky assumption
> that your adversaries will cooperate by not changing tactics.

I don't think you read what I said.
 
>>>   - basic protocol vulnerable to attacks by bad guys (SPF/RMX/etc.
>>>       are not quite as wide-open as IDENT/TAP)
>>
>>I don't see this one at all.
> 
> IDENT depends on easily forged and inserted UDP/IP packets.  SPF/RMX/etc
> also depends on UDP/IP packets, somewhat more difficult to forge and
> insert...or were you going to wait to decide whether SPF/RMX/etc is
> useful until after DNS-SEC is deployed?

Am I dense or is ident a tcp based protocol?

> Anyone whose brain is not so open that it falls out looked at the idea
> of SPF/RMX/etc many years ago and decide it wasn't worth the effort.
> For example, see
> http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00658.html

Interesting, noted.

M4
-- 
Redundancy is a great way to introduce more single points of failure.

In article <pan.2004.10.10.20.16.40.482190@remove.this.part.rtij.nl>,
Martijn Lievaart  <m@remove.this.part.rtij.nl> wrote:

>> have often written.  SPF fails dismally as an anti-forgery measure,
>> because if it were deployed, it would detect as "forged" a lot of
>> legitimate mail such as from roaming users.  It cannot detect much of
>
>Roaming users are a problem, not just for SPF. 

Of course, because roaming users make practically impossible any useful
(by computers) definition of "forged" that is not MUA/end-to-MUA/end.
The only solutions that are end-to-end are forms of digital signatures,
by any reasonably general definition of "digital signature."


>                                               A problem which is
>trivially solved btw. 

There are only two solutions for the roaming-users-seen-as-forgery
problem.  They are digital signatures and outlawing roaming users,
neither of which do anything significant about spam.

>                      Forwarded mail is a much bigger problem.

We disagree.  I see forwarded mail as a major but smaller problem,
perhaps because I'm more willing to outlaw forwarding.  (Note that I
personally have almost never been a roaming user because I have always
used rlogin/telnet/ssh to send from my home MTAs.  I have done mail
forwarding for myself and users.)


>> any truly forged mail unless it is widely deployed, but because of its
>> many practical problems and lack of effect on spam, it will never be
>> deployed.  If you are designing for the world as SPF fans wish it were,
>> then SPF is great; it only fails dismally in the real world.
>
>So it fails because it is not employed? I'm not going to split those hairs.

No, it fails not because it is not yet deployed but because it will
never be deployed.  That which is useless because practically no one
will ever deploy it is a classic kook FUSSP.  SPF is a cure for forgery
in the same way sexual abstinance is a cure for AIDS.  Both might be
effective if they were deployed, but they never will be.  Related
efforts like SMTP-AUTH/TLS can help, but they are not cures.  The
stop-spam-by-SPF/RMX public policy advocates do not advert to the
existence of SMTP-AUTH/TLS because they are related mechanisms, widely
deployed, and have not been cures.


>>>Also note that I did not say that SPF is the answer here, only that
>>>digital signatures are an even worse idea in this context.
>> 
>> Yes, but that's a red herring.  No one in this thread suggested using
>> signatures for detecting forged spam.  The other person's point was
>
>Then why bring it up?

Because SPF advocates keep repeating their dishonest talk about SPF
being a solution for forgery.  It is another parallel with IDENT.  When
you point out to fans that their panacea has no effect on the reason
their thing exists (spam or security attacks), they switch to dishonest
statements that "SPF/IDENT is not supposed to stop spam/security attacks
but only stop forgery/help audit trails."  When you point out that SPF
is not forgery solution in the real world and that the IDENT audit
trail is useless unless the client has good logs and unneeded when
it does, advocates complain that digital signatures are useless against
spam and that you can't force other people to have good logs.  The
next time you encounter them, they are back to lies like those on
http://spf.pobox.com about SPF being a spam solution:

    SPF fights email address forgery and makes it easier to identify
    spams, worms, and viruses.

    SPF is ushering in a new set of anti-spam systems, where email
    is spam unless proven otherwise

http://spf.pobox.com will never admit that SPF is at best a forgery
solution and not a spam solution is that no one would pay for
certification (see <http://spf.pobox.com/certification.html>),
consulting (see <http://spf.pobox.com/services.html>), trade rag espurt
babble, or anything else merely to stop MTA-to-MTA forgery...or if they
would pay, they'd buy SMTP-TLS or SMTP-AUTH.


>> IDENT depends on easily forged and inserted UDP/IP packets.  SPF/RMX/etc
>> also depends on UDP/IP packets, somewhat more difficult to forge and
>> insert...or were you going to wait to decide whether SPF/RMX/etc is
>> useful until after DNS-SEC is deployed?
>
>Am I dense or is ident a tcp based protocol?

Yes, IDENT uses UDP/IP.  Doesn't SPF involve DNS RRs?  Don't those
curently generally come via UDP/IP?


Vernon Schryver    vjs@rhyolite.com

On Sun, 10 Oct 2004 15:10:40 -0600, Vernon Schryver wrote:

>>                                               A problem which is
>>trivially solved btw. 
> 
> There are only two solutions for the roaming-users-seen-as-forgery
> problem.  They are digital signatures and outlawing roaming users,
> neither of which do anything significant about spam.

Just open up a MSA port and let users authenticate. Add webmail for
when that is impractcal. End of problem.

> 
>>                      Forwarded mail is a much bigger problem.
> 
> We disagree.  I see forwarded mail as a major but smaller problem,
> perhaps because I'm more willing to outlaw forwarding.  (Note that I
> personally have almost never been a roaming user because I have always
> used rlogin/telnet/ssh to send from my home MTAs.  I have done mail
> forwarding for myself and users.)

Well let's disagree on that one. 
 
> No, it fails not because it is not yet deployed but because it will
> never be deployed.  That which is useless because practically no one
> will ever deploy it is a classic kook FUSSP.  SPF is a cure for forgery
> in the same way sexual abstinance is a cure for AIDS.  Both might be
> effective if they were deployed, but they never will be.  Related
> efforts like SMTP-AUTH/TLS can help, but they are not cures.  The
> stop-spam-by-SPF/RMX public policy advocates do not advert to the
> existence of SMTP-AUTH/TLS because they are related mechanisms, widely
> deployed, and have not been cures.

Again, you are reading things into my reply I have not said. I'm going to
drop this now.

>>> IDENT depends on easily forged and inserted UDP/IP packets.
>>> SPF/RMX/etc also depends on UDP/IP packets, somewhat more difficult to
>>> forge and insert...or were you going to wait to decide whether
>>> SPF/RMX/etc is useful until after DNS-SEC is deployed?
>>
>>Am I dense or is ident a tcp based protocol?
> 
> Yes, IDENT uses UDP/IP.  Doesn't SPF involve DNS RRs?  Don't those
> curently generally come via UDP/IP?

Ident: RFC 1413. And did you actually look into DNS spoofing?

M4
-- 
Redundancy is a great way to introduce more single points of failure.

John F Hall <jfh@avondale.demon.co.uk> wrote:
>   Received: from lon1-punt3-1.mail.demon.net
> 	(lon1-punt3-1.mail.demon.net +[194.217.242.164]) by
> 	avondale.demon.co.uk (8.12.11/8.12.9) with SMTP id
> 	i8CHNPPP000958 for <jfh@avondale.demon.co.uk>; Sun, 12 Sep 2004
> 	18:27:43 +0100

In normal terms this is the *only* received header that you can trust,
because it was added by your server (or a server that you have to
trust). Everything else could have been forged.

>   Received: from punt-3.mail.demon.net by mailstore
>         for jfh@avondale.demon.co.uk id 1C6OaG-0002TF-78;
>         Sun, 12 Sep 2004 07:15:36 +0000
>   Received: from [194.217.242.71] (helo=anchor-hub.mail.demon.net)
> 	by punt-3.mail.demon.net with esmtp id 1C6OaG-0002TF-78 for
> 	jfh@avondale.demon.co.uk; Sun, 12 Sep 2004 07:15:36 +0000
>   Received: from [202.224.159.140] (helo=smaster3.hi-ho.ne.jp)
> 	by anchor-hub.mail.demon.net with esmtp id 1C6OaF-00022g-09 for
> 	jfh@avondale.demon.co.uk; Sun, 12 Sep 2004 07:15:36 +0000

In Demon's case you can probably trust down to here, due to the split
front/back end systems it uses. From here on you cannot trust anything
you see; to verify these entries you have to contact the owner of each
preceding mail server.

>   Received: from max.hi-ho.ne.jp (sproxy33 [192.168.125.209])
> 	by smaster3.hi-ho.ne.jp (hi-ho Mail Server) with ESMTP id
> 	<0I3X00CB20POJB@smaster3.hi-ho.ne.jp> for
> 	jfh@avondale.demon.co.uk; Sun, 12 Sep 2004 15:29:48 +0900 (JST)
>   Received: from igld (west27-p8.eaccess.hi-ho.ne.jp [218.228.106.9])
> 	by max.hi-ho.ne.jp     id EOTC34D0; Sun, 12 Sep 2004 15:29:22
> 	+0900 (JST)

Chris

* Sun 2004-10-10 vjs AT calcite.rhyolite.com (Vernon Schryver) comp.mail.misc
| Because SPF advocates keep repeating their dishonest talk about SPF
| being a solution for forgery. 

Could you explain this more. I was under impression that where SPF
helps, is that, when used, it reuires mail to travel through
authorized routes only. Like:

        A -> (1) ->(2) -> (3) -> B

Here,  cannot contact B directly and pretend to come from C, because SPF
would reveal the forgery.

The B's SPF call (DNS query to A's DNS RR TXT) would say that mail coming
from A, must come through A's MXs(1) only.

Is this the correct interpretation? 

Jari

In article <pan.2004.10.11.07.07.12.118918@remove.this.part.rtij.nl>,
Martijn Lievaart  <m@remove.this.part.rtij.nl> wrote:


>> There are only two solutions for the roaming-users-seen-as-forgery
>> problem.  They are digital signatures and outlawing roaming users,
>> neither of which do anything significant about spam.
>
>Just open up a MSA port and let users authenticate. Add webmail for
>when that is impractcal. End of problem.

That amounts to outlawing roaming users.  That you use restricted SMTP
and HTTP intead of rlogin, telnet, or ssh to tunnel roaming users back
to their home MTAs is irrelevant.  Roaming users are not merely people
not at their desks but people using strange MTAs.

You might think outlawing roaming is ok, if you believe that double-hop
firewalls no longer exist, that HTTP to everywhere is available
everywhere, and other things that are false or if you think that anyone
temporarily roaming behind such barriers should simply wait to to send mail.


>>>Am I dense or is ident a tcp based protocol?
>> 
>> Yes, IDENT uses UDP/IP.  Doesn't SPF involve DNS RRs?  Don't those
>> curently generally come via UDP/IP?
>
>Ident: RFC 1413. And did you actually look into DNS spoofing?

Interesting.  For some reason I was sure IDENT was UDP based.

For DNS spoofing, are you assuming that it is sufficiently hard for
a bad guy to predict the 16-bit ID in the header of an DNS response?
If so, please check http://www.google.com/search?q=dns+spoof and
especially http://www.securityfocus.com/guest/17905


Vernon Schryver    vjs@rhyolite.com