COMPGROUPS.NET | Search | Post Question | Groups | Stream | About | Register

### Microsoft spam solution turned down by IETF - is there a Linux/open source alternative?

• Email
• Follow

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?


 0

See related articles to this posting

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   0 Reply spambait1 (6) 9/19/2004 5:26:02 PM 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

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

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

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

.....

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

 0

Alan Connor wrote:

> In this example, AOL.com is the sending domain, and
>
> 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.

 0

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

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


 0

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

 0

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
>

It's still a big improvement.

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

 0

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

 0

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.

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.

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.

authorised to send email with a from address containing

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.


 0

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?


 0

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?


 0

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

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

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?


 0

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

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

Sending eMail to other SMTP servers is a privilege.


 0

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

 0
Reply vjs (40) 9/20/2004 5:12:25 AM

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.


 0
Reply daveuhring (1185) 9/20/2004 5:29:48 AM

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:

Name:   netware.inter-corporate.com

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.

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


 0
Reply daveuhring (1185) 9/20/2004 5:44:32 AM

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?


 0
Reply daveuhring (1185) 9/20/2004 5:51:27 AM

"vjs@calcite.rhyolite.com (Vernon Schryver)" wrote in

[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

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

Sending eMail to other SMTP servers is a privilege.


 0

"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"?

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

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

--
Randolf Richardson, pro-active spam fighter - rr@8x.ca

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

Sending eMail to other SMTP servers is a privilege.


 0

"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:
>
> Name:   netware.inter-corporate.com
>
> 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

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

Sending eMail to other SMTP servers is a privilege.


 0

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

 0

"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

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

Sending eMail to other SMTP servers is a privilege.


 0

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

> SPF's big advantage is that it provides for authentication of
> domains without blocking domains that have not subscribed to
> 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

 0

"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

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

Sending eMail to other SMTP servers is a privilege.


 0

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

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

 0

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

 0

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
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9425

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

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

 0
Reply bill123 (477) 9/20/2004 11:38:59 AM

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:
>
> Name:   netware.inter-corporate.com
>
> 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
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17684

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

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.

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

 0
Reply bill123 (477) 9/20/2004 11:45:48 AM

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
"private DNS," and related concepts.

Vernon Schryver    vjs@rhyolite.com

 0
Reply vjs (40) 9/20/2004 2:11:38 PM

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

 0
Reply johnww (70) 9/20/2004 3:38:13 PM

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>

 0

"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

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

Sending eMail to other SMTP servers is a privilege.


 0

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?
> >
> >
>
> 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
nameserver names returned by the prior query, how else will it know

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.

 0

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)

--
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!

 0
Reply dplatt (36) 9/20/2004 4:52:38 PM

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

He wants every mail to have

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!
������������������������������������������������������������������������

 0
Reply from (543) 9/20/2004 5:00:35 PM

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


 0

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

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:,
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

 0
Reply gfy1 (4) 9/20/2004 6:19:45 PM

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.

 0

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

 0
Reply cfajohnson (1827) 9/20/2004 6:54:52 PM

"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.   0 Reply Blane 9/20/2004 7:14:27 PM 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   0 Reply Steve 9/20/2004 7:40:49 PM 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

 0

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

 0
Reply nospam5 (163) 9/20/2004 7:57:28 PM

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

 0
Reply cfajohnson (1827) 9/20/2004 8:07:12 PM

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

 0
Reply kkeller-usenet (1299) 9/20/2004 8:16:34 PM

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

 0
Reply SPAMhukolauTRAP (330) 9/20/2004 8:21:09 PM

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   0 Reply Alan 9/20/2004 8:36:20 PM 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 ������������������������������������������������������������������������   0 Reply Alexander 9/20/2004 9:07:23 PM 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   0 Reply ptb (2763) 9/20/2004 9:59:38 PM 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--   0 Reply Sam 9/20/2004 10:38:25 PM 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   0 Reply Dimitri 9/21/2004 12:10:44 AM 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   0 Reply johnww (70) 9/21/2004 12:20:16 AM "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.   0 Reply Randolf 9/21/2004 2:18:50 AM 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   0 Reply af380 (28) 9/21/2004 2:27:28 AM "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.   0 Reply Randolf 9/21/2004 2:31:20 AM "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.   0 Reply Randolf 9/21/2004 2:37:51 AM "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.   0 Reply Randolf 9/21/2004 2:39:36 AM 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
>>
>>Sender Policy Framework http://spf.pobox.com/
>>
>
>
> Looks promising. From that site:
>
> <quote>
>
> In this example, AOL.com is the sending domain, and
>
> 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.


 0

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

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

 0

Randolf Richardson wrote:
>
> [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)
>
>
>     	...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
������������������������������������������������������������������������

 0
Reply from (543) 9/21/2004 4:30:20 AM

Randolf Richardson wrote:
> "Alexander Skwar <from@alexander.skwar.name>" wrote in
>
>
>>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).
>
>
>>
>>He wants every mail to have
>>
>>
>>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
������������������������������������������������������������������������

 0
Reply from (543) 9/21/2004 4:33:40 AM

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

 0

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

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

 0
Reply from (543) 9/21/2004 4:37:47 AM

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
>
>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
http://www.xhome.org  My Sales Code is 22819

 0

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

 0
Reply cfajohnson (1827) 9/21/2004 7:25:49 AM

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

 0
Reply nospam5 (163) 9/21/2004 7:59:17 AM

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.   0 Reply Murray 9/21/2004 9:13:39 AM 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
>
>

 0

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,


 0

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

 0
Reply JunkDTectr (9) 9/21/2004 9:13:40 AM

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

 0

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

 0
Reply john4584 (1601) 9/21/2004 1:15:20 PM

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

 0

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.

 0

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

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

 0

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

 0
Reply cfajohnson (1827) 9/21/2004 7:39:18 PM

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.


 0
Reply daveuhring (1185) 9/21/2004 8:11:50 PM

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

> Randolf Richardson wrote:
>
>>
>>>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)
>>
>> ...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

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

Sending eMail to other SMTP servers is a privilege.


 0

"Alexander Skwar <from@alexander.skwar.name>" wrote in

> Randolf Richardson wrote:
>
>> "Alexander Skwar <from@alexander.skwar.name>" wrote in
[sNip]
>>>
>>>He wants every mail to have
>>>
>>>
>>>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

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

Sending eMail to other SMTP servers is a privilege.


 0

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in

[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

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

Sending eMail to other SMTP servers is a privilege.


 0

"Alexander Skwar <from@alexander.skwar.name>" wrote in

> 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

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

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

Sending eMail to other SMTP servers is a privilege.


 0

"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

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

Sending eMail to other SMTP servers is a privilege.


 0

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

 0

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

 0

Randolf Richardson wrote:
> "Alexander Skwar <from@alexander.skwar.name>" wrote in news.admin.net-
> abuse.email:
>
>
>>Randolf Richardson wrote:
>>
>>
>>>
>>>
>>>>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)
>>>
>>>...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.

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

 0
Reply from (543) 9/22/2004 7:47:49 AM

Randolf Richardson wrote:
> ""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
>
>
>
> [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. *
>>
>
>
>     	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
������������������������������������������������������������������������

 0
Reply from (543) 9/22/2004 7:49:03 AM

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

 0

Randolf Richardson wrote:
> "Alexander Skwar <from@alexander.skwar.name>" wrote in
>
>
>>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
>
>
>     	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
this?

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

 0
Reply from (543) 9/22/2004 7:52:38 AM

Randolf Richardson wrote:
> "Alexander Skwar <from@alexander.skwar.name>" wrote in
>
>
>>Randolf Richardson wrote:
>>
>>
>>>"Alexander Skwar <from@alexander.skwar.name>" wrote in
>
> [sNip]
>
>>>>
>>>>He wants every mail to have
>>>>
>>>>
>>>>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
������������������������������������������������������������������������

 0
Reply from (543) 9/22/2004 7:57:03 AM

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

 0

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

 0

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

 0

"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


 0

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

 0

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.

 0
Reply jfh1 (1) 9/22/2004 9:33:51 AM

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

 0

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

 0

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.

 0

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

 0
Reply usenet132 (379) 9/22/2004 2:50:37 PM

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

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

 0

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

 0
Reply john4584 (1601) 9/22/2004 3:02:27 PM

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

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

 0
Reply from (543) 9/22/2004 3:11:36 PM

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.

 0
Reply usenet132 (379) 9/22/2004 8:12:56 PM

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

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

 0

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.

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

--=_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--

 0

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:

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

 0

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

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

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

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

 0

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

 0

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.

 0

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

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

 0

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

 0

Sam wrote:
> Alexander W. Skwar writes:
>
>
>>
>>
>>>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
������������������������������������������������������������������������

 0

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.

--
[email me at huge [at] huge [dot] org [dot] uk]


 0

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in

>
>> "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?
>>
>
> Fine.
[sNip]

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

--
Randolf Richardson, pro-active spam fighter - rr@8x.ca

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

Sending eMail to other SMTP servers is a privilege.


 0

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

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

Sending eMail to other SMTP servers is a privilege.


 0

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in

> Randolf Richardson wrote:
>> "Alexander 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.

[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

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

Sending eMail to other SMTP servers is a privilege.


 0

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in

> Randolf Richardson wrote:
>
>> "Alexander Skwar <from@alexander.skwar.name>" wrote in
>>
>>>Randolf Richardson wrote:
>>>
>>>>"Alexander Skwar <from@alexander.skwar.name>" wrote in
>>>>
>>>>>
>>>>>He wants every mail to have
>>>>>
>>>>>
>>>>>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?

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

--
Randolf Richardson, pro-active spam fighter - rr@8x.ca

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

Sending eMail to other SMTP servers is a privilege.


 0

Randolf Richardson wrote:
> ""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
>
>
>>
>>
>>>"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?
>>>
>>
>>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
������������������������������������������������������������������������

 0
Reply from (543) 9/23/2004 10:41:02 AM

Randolf Richardson wrote:
> ""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
>
>
>>Randolf Richardson wrote:
>>
>>>"Alexander 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.

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

 0
Reply from (543) 9/23/2004 10:42:39 AM

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

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

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

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

--
Hallvard

 0

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>

 0

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

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

Sending eMail to other SMTP servers is a privilege.


 0

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

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.

> 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

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

 0

""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in

> Randolf Richardson wrote:
>
>> ""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
>>
>>>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

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

Sending eMail to other SMTP servers is a privilege.


 0

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
To the spammers, my motto: FABRICATI DIEM, PVNC.

 0
Reply spam95 (5707) 9/23/2004 4:45:27 PM

> 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

 0

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

 0

Randolf Richardson wrote:
> ""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
>
>
>>Randolf Richardson wrote:
>>
>>
>>>""Alexander W. Skwar" <from@alexander.skwar.name>" wrote in
>>>
>>>
>>>>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
������������������������������������������������������������������������

 0
Reply from (543) 9/23/2004 5:55:00 PM

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

 0
Reply from (543) 9/23/2004 5:59:54 PM

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

 0
Reply from (543) 9/23/2004 6:00:57 PM

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

 0

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.

 0

In article <415252EF.40001@von.digitalprojects.com>,
>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.

 0

"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


 0

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   0 Reply No 9/23/2004 6:39:33 PM 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   0 Reply spammers_lie 9/23/2004 7:03:56 PM "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.   0 Reply Randolf 9/23/2004 7:47:38 PM "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.   0 Reply Randolf 9/23/2004 7:50:17 PM 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.   0 Reply pv 9/23/2004 7:58:33 PM 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.   0 Reply The 9/23/2004 8:15:31 PM 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   0 Reply cfajohnson (1827) 9/23/2004 8:25:02 PM 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.   0 Reply spam95 (5707) 9/23/2004 8:30:22 PM 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.


 0

Murray Watson <JunkDTectr@adelphia.net> wrote in

> <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   0 Reply No 9/23/2004 8:54:09 PM 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. ������������������������������������������������������������������������   0 Reply from (543) 9/23/2004 9:32:22 PM 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." ������������������������������������������������������������������������   0 Reply from (543) 9/23/2004 9:33:18 PM 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- ) )-,_..;\ ( '-' '---''(_/--' -'\_)   0 Reply Travis 9/23/2004 10:21:04 PM 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--   0 Reply Sam 9/23/2004 10:30:41 PM 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--   0 Reply Sam 9/23/2004 10:43:11 PM 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--   0 Reply Sam 9/23/2004 10:43:17 PM 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   0 Reply neosad1st (530) 9/24/2004 12:58:03 AM "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"?   0 Reply cbbrowne (1108) 9/24/2004 1:24:20 AM "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.   0 Reply Randolf 9/24/2004 1:24:59 AM 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>   0 Reply Jonathan 9/24/2004 3:50:10 AM 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 ������������������������������������������������������������������������   0 Reply Alexander 9/24/2004 4:24:04 AM 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 ������������������������������������������������������������������������   0 Reply Alexander 9/24/2004 4:25:52 AM 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 ������������������������������������������������������������������������   0 Reply from (543) 9/24/2004 4:27:29 AM 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--   0 Reply Sam 9/24/2004 11:17:11 AM 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--   0 Reply Sam 9/24/2004 11:17:12 AM 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>   0 Reply Jonathan 9/24/2004 3:43:04 PM 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   0 Reply Alan 9/24/2004 3:52:12 PM 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.   0 Reply pv 9/24/2004 5:06:34 PM 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.   0 Reply spam95 (5707) 9/24/2004 5:15:34 PM 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.   0 Reply jfh 9/24/2004 8:03:40 PM 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.   0 Reply The 9/24/2004 8:45:10 PM 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

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.


 0

Murray Watson <JunkDTectr@adelphia.net> wrote in

> <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
>>
>> > 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   0 Reply No 9/24/2004 10:00:50 PM 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   0 Reply Jari 9/24/2004 11:01:30 PM 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.   0 Reply jfh 9/25/2004 12:37:40 AM 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.   0 Reply Murray 9/25/2004 2:20:55 AM 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/   0 Reply Morely 9/25/2004 4:45:13 PM 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.   0 Reply jfh 9/25/2004 7:27:03 PM 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   0 Reply Terry 9/25/2004 9:01:05 PM 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/   0 Reply Morely 9/26/2004 1:30:20 AM "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.   0 Reply Randolf 9/26/2004 9:51:34 AM 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   0 Reply Alan 9/26/2004 11:41:05 AM 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   0 Reply Shmuel 9/26/2004 1:02:39 PM 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.

--

 0

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>

 0

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

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.

 0

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   0 Reply Alan 9/26/2004 3:58:04 PM 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?

Did you run out of arguments? Is this the debate level you prefer?

--

 0

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.   0 Reply jfh 9/26/2004 7:27:58 PM * 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   0 Reply Troy 9/26/2004 10:49:50 PM 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--   0 Reply Sam 9/26/2004 11:15:31 PM 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   0 Reply Alan 9/27/2004 12:02:55 AM 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   0 Reply Kevin 9/27/2004 12:24:20 AM * 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 / &

 0

* 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

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

 0

"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.   0 Reply Randolf 9/27/2004 4:09:20 AM 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
mails using his fundamentally broken C/R system.

> I would imagine this is not an option for those of us who are just

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.

--

 0

* 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   0 Reply Troy 9/27/2004 1:40:58 PM 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   0 Reply Mark 9/27/2004 3:25:09 PM 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.   0 Reply pv 9/27/2004 4:29:06 PM * 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   0 Reply Troy 9/27/2004 10:00:21 PM 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   0 Reply Shmuel 9/27/2004 10:27:25 PM 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   0 Reply Alan 9/27/2004 11:05:18 PM 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--   0 Reply Sam 9/27/2004 11:33:12 PM 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   0 Reply Mark 9/28/2004 5:17:02 AM "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   0 Reply Kari 9/28/2004 1:38:31 PM 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

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

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.

 0


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   0 Reply Norman 9/29/2004 12:55:13 AM 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

 0

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

 0

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

>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

>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


 0

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

 0

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   0 Reply philip 9/29/2004 8:20:00 PM 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   0 Reply sethb 9/29/2004 10:10:19 PM 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
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.

 0

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.

 0

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.   0 Reply jfh 9/29/2004 11:13:05 PM 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/   0 Reply Morely 9/30/2004 4:00:18 AM ""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.   0 Reply Randolf 9/30/2004 7:42:44 AM 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 ������������������������������������������������������������������������   0 Reply Alexander 9/30/2004 7:43:25 AM 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.   0 Reply Jonathan 9/30/2004 3:43:06 PM ""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.   0 Reply Randolf 9/30/2004 5:36:55 PM 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.   0 Reply jfh 9/30/2004 10:32:29 PM 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.   0 Reply The 9/30/2004 11:15:20 PM 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   0 Reply Steve 10/1/2004 3:02:10 AM 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.   0 Reply The 10/1/2004 4:30:34 PM 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.   0 Reply jfh 10/1/2004 8:52:22 PM 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.   0 Reply The 10/1/2004 11:30:07 PM 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.   0 Reply jfh 10/2/2004 10:48:34 PM 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   0 Reply Norman 10/3/2004 7:54:58 AM 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.   0 Reply jfh 10/3/2004 6:18:44 PM 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   0 Reply Shmuel 10/3/2004 8:43:48 PM 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


 0

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


 0

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.

 0

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


 0

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

 0

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

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

 0

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.   0 Reply jfh 10/4/2004 7:02:37 PM 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.

 0

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

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

 0

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   0 Reply sethb 10/4/2004 7:47:06 PM 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   0 Reply sethb 10/4/2004 7:54:16 PM 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   0 Reply sethb 10/4/2004 7:59:16 PM 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.   0 Reply pv 10/4/2004 8:59:01 PM 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.   0 Reply pv 10/4/2004 9:13:06 PM 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
>
>    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
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

 0

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.

 0

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


 0

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

 0

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:

Why? What perrcentage of false positives do you consider acceptable
for dropping into /dev/null?

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


 0

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


 0

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


 0

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

 0

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


 0

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

 0

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   0 Reply Shmuel 10/7/2004 2:54:36 PM 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.

 0

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

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.

 0

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.   0 Reply jfh 10/7/2004 9:42:02 PM 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.   0 Reply jfh 10/7/2004 10:04:58 PM 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:
>
>
>Why? What perrcentage of false positives do you consider acceptable
>for dropping into /dev/null?
>
>
>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.

 0

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   0 Reply Norman 10/8/2004 1:19:33 AM 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.   0 Reply Jonathan 10/8/2004 3:43:05 AM 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.   0 Reply Jonathan 10/8/2004 3:43:06 AM * 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   0 Reply Jari 10/8/2004 4:40:20 AM 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.   0 Reply The 10/8/2004 3:15:33 PM "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.   0 Reply The 10/8/2004 3:15:35 PM 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.   0 Reply The 10/8/2004 3:15:36 PM 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   0 Reply Norman 10/8/2004 3:46:47 PM "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.   0 Reply The 10/8/2004 8:45:44 PM 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.   0 Reply jfh 10/8/2004 10:07:11 PM 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.

 0

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.


 0

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

 0

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


 0

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.


 0

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.


 0

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

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

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

 0

>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

I thought one of the biggest problems with SPF was that spammers were
adopting it faster than real companies.


 0

On Sun, 10 Oct 2004 08:52:42 -0600, Vernon Schryver wrote:

> Please check who said what in this thread.  The words above "fails

> 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

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.


 0

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

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

 0

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


 0

John F Hall <jfh@avondale.demon.co.uk> wrote:
> 	(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
> 	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
> 	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

 0

* Sun 2004-10-10 vjs AT calcite.rhyolite.com (Vernon Schryver) comp.mail.misc
| 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

 0

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?
especially http://www.securityfocus.com/guest/17905

Vernon Schryver    vjs@rhyolite.com

 0

On Mon, 11 Oct 2004 09:10:01 -0600, Vernon Schryver wrote:

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

Those users are not part of the problem anyhow.

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

I personally never saw a setup where a roaming user could use port 25, but
not any of those other methods. If that is collateral damage, so be it. I
don't think that is a realistic example.

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

Never mind, all other things you said about it are true. It has almost no
practical value and causes more grief than it does good. It most certainly
is not an anti forgery method, more a debugging aid.

> 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?
> especially http://www.securityfocus.com/guest/17905

That is what I called hard. Not impossible, but not practical in the
context discussed here. Probably someone will do it one day.

Do note that if you know the victim uses a Windows resolver, the odds
suddenly get a /whole/ lot better for the attacker. If this is the case
for the MS DNS servers I don't know, but history teaches it takes
microsoft a few tries before actually getting it right, so I would not bet
on it being better.

M4
--
Redundancy is a great way to introduce more single points of failure.


 0

In article <416891a1$3$fuzhry+tra$mr2ice@news.patriot.net>, Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote: >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: >>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. I've struggled to make sense of that, and have totally failed. Yes, it's a relay. It's an *MTA* - *all* MTAs are relays. (It's *MUAs* that originate emails - everything afterwards relays it.) No, it shouldn't be blocked - unless you're intending to block every MTA. Are you confusing "relay" with "open relay"? If so you appear to have forgotten the definition of an "open relay". Closed relays relay only *to* local and supported mail domains, or *from* senders that are authenticated (from known IP addresses, or from users that have explicitly authenticated). All others (including those that base their authentication on the sender's email address) are open relays. As for "checking the user's identity", *my* computer knows the user identity - users have to login, I control physical access, and it's rare for it to be anyone but me. But any system I connect to - whether Demon, Freeserve, Compuserve, or whatever - knows only the *account*, the *computer*, that is connected, together with the calling phone number (or ADSL link). It has no way of knowing the *user*. Still less does it know all that user's email addresses. -- John F Hall The Internet relies on the cooperative use of private resources. Sending email is a privilege not a right.   0 Reply jfh 10/11/2004 6:51:54 PM Martijn Lievaart wrote: > On Mon, 11 Oct 2004 09:10:01 -0600, Vernon Schryver wrote: > > >> >>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. > > Those users are not part of the problem anyhow. > >>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. > > I personally never saw a setup where a roaming user could use port 25, but > not any of those other methods. If that is collateral damage, so be it. I > don't think that is a realistic example. > Roaming user should *never* be using port 25 to inject mail. They should be using SMTP Auth (port 587). This requires a user ID and password to get into their employer's or their ISP's mail server. Anything else is subject to abuse. The "outlawing roaming" is a red herring. SMTP Auth is the answer. An alternative is webmail. Webmail (see squirlmail as an example of webmail) also requires a user ID and password to gain access. -- 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   0 Reply Rex 10/11/2004 8:20:25 PM In article <pan.2004.10.11.17.18.05.474166@remove.this.part.rtij.nl>, Martijn Lievaart <m@remove.this.part.rtij.nl> wrote: >> 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. > >I personally never saw a setup where a roaming user could use port 25, but >not any of those other methods. If that is collateral damage, so be it. I >don't think that is a realistic example. I prefer listing at the start the costs of things, such as outlawing some historically permitted activities. Outlawing roaming users is a plausible cost. I think I disagree, but your position seems reasonable. >> 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 > >That is what I called hard. Not impossible, but not practical in the >context discussed here. Probably someone will do it one day. All attacks should be evaluated by comparing the costs of the attack with the benefits. Please read the nice descriptions of the attacks in http://www.securityfocus.com/guest/17905 I agree that making more than 350 spoofed DNS responses, to get through the SPF defenses of a vanity domain would be a waste of effort for a spammer. However, getting through the SPF defenses of an AOL would be far more valueable to a spammer. Even sending 65536 spoofed responses with 100.0% probability of poking a hole through the SPF defenses of an AOL that would last for months or until it was manually purged from the target's DNS cache sounds profitable even for the relatively low returns for spamming. (Assuming no alarms go off when 64K responses to a single query are received. If that is a problem, you'd have to spread out your attacks and use smaller batches of spoofed responses.) (Of course, you'd want to spread out the responses over a 30 second or perhaps 90 second period.) -- Vernon Schryver vjs@rhyolite.com   0 Reply vjs 10/11/2004 9:10:48 PM In article <jm2q32-qqo.ln1@moldev.cmagroup.co.uk>, <chris-usenet@roaima.co.uk> wrote: >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. But before I posted it I did a consistency check, looking at times, timezones, IP addresses, hostnames, and general appearence of the headers. Sure they might be forged, but they don't appear to be. Also I chose a virus as that was the topic under discussion. I could equally have chosen valid emails - that I *know* had no forged headers - to illustrate that email to me is relayed *before* being offered to Demon (or therefore any other "recipient" MTA), so that a reject will raise a DSN. (I could email quote emails from people in n.a.n-a.e :-).) So I am *not* talking about anything special to Demon - as I've said several times. -- John F Hall The Internet relies on the cooperative use of private resources. Sending email is a privilege not a right.   0 Reply jfh 10/12/2004 11:48:30 AM On Mon, 11 Oct 2004 15:10:48 -0600, Vernon Schryver wrote: >>I personally never saw a setup where a roaming user could use port 25, but >>not any of those other methods. If that is collateral damage, so be it. I >>don't think that is a realistic example. > > I prefer listing at the start the costs of things, such as outlawing > some historically permitted activities. Outlawing roaming users is a > plausible cost. I think I disagree, but your position seems reasonable. I certainly don't want to outlaw roaming users! Point is, your objections seem only to apply to users that are behind a firewall, and inherently -- roaming, so not at home there -- must use resources of others. I find it difficult to believe there are many setups where the user can either use port 25 outbound or a local mailserver, while not having access to the MSA port and/or webmail and/or ssh (can be perfectly proxied over most https proxies) and/or other methods. I personally use webmail, ssh-shell access and ssh-tunneling for roaming access. The company I work for uses webmail and VPNs. > However, getting through the SPF defenses of an AOL would be far more > valueable to a spammer. Even sending 65536 spoofed responses with > 100.0% probability of poking a hole through the SPF defenses of an AOL > that would last for months or until it was manually purged from the > target's DNS cache sounds profitable even for the relatively low returns > for spamming. (Assuming no alarms go off when 64K responses to a single > query are received. If that is a problem, you'd have to spread out your > attacks and use smaller batches of spoofed responses.) (Of course, > you'd want to spread out the responses over a 30 second or perhaps 90 > second period.) You certainly have a point here. This scenario is criminal, but that hasn't stopped spammers in the least. BTW I doubt you can do this with 65536 packets, timing is critical as the packet must match a reply. Assuming they don't take out the real dns server first they must also race that server, so I still doubt if the scenario is practical. M4 -- Redundancy is a great way to introduce more single points of failure.   0 Reply Martijn 10/12/2004 1:05:22 PM In <ckekoa$s04$1@avondale.demon.co.uk>, on 10/11/2004 at 06:51 PM, jfh@avondale.demon.co.uk (John F Hall) said: >I've struggled to make sense of that, and have totally failed. Perhaps it would be easier if you read RFC 2821. >Yes, it's a relay. It's an *MTA* - *all* MTAs are relays. No. >Are you confusing "relay" with "open relay"? No, I'm confusing "relay" with "relay as defined in RFC 2821". Perhaps you have some reason for not considering that definition to be relevant to discussions of mail servers? >Still less does it know all that user's email addresses. It doesn't need to know all of the users addresses. It only needs to know the addresses that are valid for the account that the user is using. -- 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   0 Reply Shmuel 10/12/2004 7:11:25 PM In <Pine.GSO.3.95.iB1.0.1041007220739.24766A-100000@halifax.chebucto.ns.ca>, on 10/07/2004 at 10:19 PM, "Norman L. DeForest" <af380@chebucto.ns.ca> said: >What I wrote is that a ***!!KNOWN!!!*** worm that is !!!**KNOWN**!!! >to forge addresses should be dropped silently. A circumstance that does not exist. You then proceeded to draw conclusions based on the assumption that it was not only possible but being done. Meanwhile, in the real world, . . . -- 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   0 Reply Shmuel 10/12/2004 10:16:46 PM On Fri, 08 Oct 2004 22:07:11 +0000, John F Hall wrote: > 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. To reiterate that point, the latest batch here: ** Know legitimate MTA (1 more not shown) Received: from netsys.com (NETSYS.COM [::ffff:199.201.233.10]) by ma.rtij.nl with esmtp; Wed, 13 Oct 2004 10:24:08 +0200 Received: from NETSYS.COM (localhost [127.0.0.1]) by netsys.com (8.11.6p2-2003-09-16/8.11.6) with ESMTP id i9D7dse00057; Wed, 13 Oct 2004 03:39:54 -0400 (EDT) Received: from J (user-24-214-239-51.knology.net [24.214.239.51]) by netsys.com (8.11.6p2-2003-09-16/8.11.6) with SMTP id i9D7USs28495 for <full-disclosure@lists.netsys.com>; Wed, 13 Oct 2004 03:30:28 -0400 (EDT) ** Looks legitimate Received: from mwinf0802.wanadoo.fr (smtp8.wanadoo.fr [::ffff:193.252.22.23]) by ma.rtij.nl with esmtp; Wed, 13 Oct 2004 07:52:22 +0200 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0802.wanadoo.fr (SMTP Server) with SMTP id A438518000CC; Wed, 13 Oct 2004 07:51:51 +0200 (CEST) Received: from sirduta (Mix-LeMans-210-1-45.w193-248.abo.wanadoo.fr [193.248.225.45]) by mwinf0802.wanadoo.fr (SMTP Server) with SMTP id D349518000C8; Wed, 13 Oct 2004 07:51:18 +0200 (CEST) ** Looks legitimate (1 more not shown) Received: from mail2.uklinux.net (mail2.uklinux.net [::ffff:80.84.72.32]) by ma.rtij.nl with esmtp; Tue, 12 Oct 2004 17:44:02 +0200 Received: from ylndzjc (adsl-static-1-99.uklinux.net [62.245.36.99]) by mail2.uklinux.net (Postfix) with SMTP id 2059840A958; Tue, 12 Oct 2004 15:38:35 +0000 (UTC) ** Looks legitimate Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [::ffff:61.8.0.84]) by ma.rtij.nl with esmtp; Mon, 11 Oct 2004 11:09:19 +0200 Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id i9B95hGx028577; Mon, 11 Oct 2004 19:05:43 +1000 Received: from jxzqd (ppp3602.dyn.pacific.net.au [61.8.54.2]) by mailproxy2.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with SMTP id i9B94bxb003826; Mon, 11 Oct 2004 19:04:38 +1000 These are the 6 last virusses I received. Note all of them went through an intermediate MTA. M4 -- Redundancy is a great way to introduce more single points of failure.   0 Reply Martijn 10/13/2004 10:02:43 AM In article <jm2q32-qqo.ln1@moldev.cmagroup.co.uk>, <chris-usenet@roaima.co.uk> wrote: >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. In comp.os.linux.misc John F Hall <jfh@avondale.demon.co.uk> wrote: > But before I posted it I did a consistency check, looking at times, > timezones, IP addresses, hostnames, and general appearence of the > headers. Sure they might be forged, but they don't appear to be. Agreed. But my point is that you cannot tell for certain. > I could equally have chosen valid emails - that I *know* had no forged > headers - to illustrate that email to me is relayed *before* being > offered to Demon (or therefore any other "recipient" MTA), so that a > reject will raise a DSN. Yes. So push the reporting onus back a level. You, or Demon on your behalf, are entitled to reject any email whatsoever. Provided you do it at the SMTP level it's then up to the sending system to determine what to do. If that's a (valid) relay site then it's up to that site to decide how, if at all, it wants to report the rejection. With SPF, it's possible for that relay to have correctly rejected the email on your behalf before even offering it to you. Chris   0 Reply chris 10/13/2004 12:47:10 PM SB> Were there some early email viruses that infected actual messages? No. D> Some of the earlier ones (Melissa?) attached themselves to otherwise D> legitimate email. No, they didn't. The source of the confusion is that Microsoft Worms such as W32/Bugbear.A@mm would use (partial) copies of existing mail messages as the templates for the (new) messages that they use to propogate themselves. Similarly, Microsoft Worms such as Melissa would send existing documents that it found, infected with itself, in its (new) mail messages. <URL:http://f-secure.com./v-descs/tanatos.shtml> <URL:http://f-secure.com./v-descs/melissa.shtml> D> anyone remember when viruses were viruses and infected D> preexisting files (and/or documents -- Word, for example) Viruses still *are* viruses (and the dichotomy that you are looking for is program/document, not file/document, by the way). That's why some people use the term "worm" (in particular, because they require Microsoft softwares in order to live, "Microsoft Worm") to refer to the things currently being discussed. (-: <URL:http://www.catb.org/~esr/jargon/html/W/worm.html> <URL:http://en.wikipedia.org/wiki/Computer_worm>   0 Reply Jonathan 10/14/2004 3:42:04 AM In article <416c3a6d$8$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <ckekoa$s04$1@avondale.demon.co.uk>, on 10/11/2004
>   at 06:51 PM, jfh@avondale.demon.co.uk (John F Hall) said:
>
>>I've struggled to make sense of that, and have totally failed.
>
>Perhaps it would be easier if you read RFC 2821.

I'm quite familiar with it, thank you.

>>Still less does it know all that user's email addresses.
>
>It doesn't need to know all of the users addresses. It only needs to
>know the addresses that are valid for the account that the user is
>using.

Perhaps you overlooked these paragraphs in RFC 2821:

7.1 Mail Security and Spoofing

SMTP mail is inherently insecure in that it is feasible for even
fairly casual users to negotiate directly with receiving and relaying
SMTP servers and create messages that will trick a naive recipient
into believing that they came from somewhere else.  Constructing such
a message so that the "spoofed" behavior cannot be detected by an
expert is somewhat more difficult, but not sufficiently so as to be a
deterrent to someone who is determined and knowledgeable.
Consequently, as knowledge of Internet mail increases, so does the
knowledge that SMTP mail inherently cannot be authenticated, or
integrity checks provided, at the transport level.  Real mail
security lies only in end-to-end methods involving the message
bodies, such as those which use digital signatures (see [14] and,
e.g., PGP [4] or S/MIME [31]).

Various protocol extensions and configuration options that provide
authentication at the transport level (e.g., from an SMTP client to
an SMTP server) improve somewhat on the traditional situation
described above.  However, unless they are accompanied by careful
handoffs of responsibility in a carefully-designed trust environment,
they remain inherently weaker than end-to-end mechanisms which use
digitally signed messages rather than depending on the integrity of
the transport system.

Efforts to make it more difficult for users to set envelope return
path and header "From" fields to point to valid addresses other than
their own are largely misguided: they frustrate legitimate
applications in which mail is sent by one user on behalf of another
or in which error (or normal) replies should be directed to a special
address.  (Systems that provide convenient ways for users to alter
these fields on a per-message basis should attempt to establish a
primary and permanent mailbox address for the user so that Sender
fields within the message data can be generated sensibly.)

This specification does not further address the authentication issues
associated with SMTP other than to advocate that useful functionality
not be disabled in the hope of providing some small margin of
protection against an ignorant user who is trying to fake mail.

--
John F Hall

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

 0

In <ckmriv$jmq$1@avondale.demon.co.uk>, on 10/14/2004
at 09:37 PM, jfh@avondale.demon.co.uk (John F Hall) said:

>I'm quite familiar with it, thank you.

Then why did you pompously give me a definition of "relay"
inconsistent with RFC 2821? Was that a deliberate misrepresentation?

>Perhaps you overlooked these paragraphs in RFC 2821:

Or perhaps I know how to use a calendar. There wasn't a massive
forged addresses when 7.1 was written.

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


 0

In article <4171d19a$4$fuzhry+tra$mr2ice@news.patriot.net>, Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote: >In <ckmriv$jmq$1@avondale.demon.co.uk>, on 10/14/2004 > at 09:37 PM, jfh@avondale.demon.co.uk (John F Hall) said: > >>I'm quite familiar with it, thank you. > >Then why did you pompously give me a definition of "relay" >inconsistent with RFC 2821? Was that a deliberate misrepresentation? > >>Perhaps you overlooked these paragraphs in RFC 2821: > >Or perhaps I know how to use a calendar. There wasn't a massive >problem with forged addresses, C/R to forged addresses and bounces to >forged addresses when 7.1 was written. Ah, I see. Some parts of that RFC are to be be given absolute authority (even when quoted with no relevance to the topic under discussion), while other parts are outdated and to be totally ignored. I'm so glad you explained :-). -- John F Hall The Internet relies on the cooperative use of private resources. Sending email is a privilege not a right.   0 Reply jfh 10/21/2004 1:18:23 AM MW> We've got to educate them on how to remove registered name servers. DU> What does that mean? MW> It's in this thread Message-ID: MW> <URL:news:///16d694b9.0409131408.216e49c4@posting.google.com> That thread would have made more sense if you and others hadn't conflated root servers, GTLD servers, and SLD servers in several places.   0 Reply Jonathan 10/21/2004 3:42:05 AM DU> What is a "registered name server" which you want removed? BC> There is a free-standing A record carried by each TLD root [...] There is no such thing as a "TLD root". It's a self-contradiction. You mean "published by each TLD content DNS server". BC> This provides a sort of backdoor nameservice that is effectively BC> bulletproof. The name is resolvable even if it is in a domain without BC> nameservice, because the TLD [content DNS servers] have that glue BC> record. Unfortunately, it's a hole in the RRP; that cannot be fixed unless the registry requires everyone to employ best practice exclusively in their delegations, and prohibits merely good practice. <URL:http://groups.google.com./groups?hl=en&lr=&c2coff=1&selm=c761kj%2418a8%241%40sf1.isc.org> <URL:http://groups.google.com./groups?hl=en&lr=&c2coff=1&selm=c761fv%241812%241%40sf1.isc.org>   0 Reply Jonathan 10/21/2004 3:42:06 AM "Jonathan de Boyne Pollard <J.deBoynePollard@Tesco.NET>" wrote in news.admin.net-abuse.email: [sNip] > That thread would have made more sense if you and others hadn't > conflated root servers, GTLD servers, and SLD servers in several places. Such advanced language could render the thread inflammable! ;-D -- Randolf Richardson, pro-active spam fighter - rr@8x.ca Vancouver, British Columbia, Canada Sending eMail to other SMTP servers is a privilege.   0 Reply Randolf 10/21/2004 4:04:16 AM In <cl72ov$53j$1@avondale.demon.co.uk>, on 10/21/2004 at 01:18 AM, jfh@avondale.demon.co.uk (John F Hall) said: >Ah, I see. Clearly not. >Some parts of that RFC are to be be given absolute authority Had I meant that I would have said so. However, when it comes to nomenclature the relevant RFC is generally the appropriate nomenclature. Bot thanks for the straw dummy. -- 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   0 Reply Shmuel 10/22/2004 5:15:40 PM On Sun, 19 Sep 2004 18:42:08 GMT, Alan Connor <zzzzzz@xxx.yyy> 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

An excellent article.

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

More than promising. It will greatly aid in the fight against
spam.

><quote>
>
> In this example, AOL.com is the sending domain, and
>

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

This is really worth looking into. Spammers don't want you
to know about it so they pretend to be spam fighters and
talk about other things to distract you.

But they aren't bright enough to change the Subject line
because they are spammers: The toilet scrubbers of the
IT world. Un-skilled labor.

--
Pro-Active Spam Fighter
Pass-list --> Block-list --> Challenge-Response
http://tinyurl.com/2t5kp

 0

Alan Connor <zzzzzz@xxx.yyy> wrote in
news:h4eed.4449$KJ6.2212@newsread1.news.pas.earthlink.net: > On Sun, 19 Sep 2004 18:42:08 GMT, Alan Connor <zzzzzz@xxx.yyy> > 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
>
> An excellent article.
>
>>>>
>>>> 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:
>>
>
> More than promising. It will greatly aid in the fight against
> spam.

Given that more spam is SPF compliant already than real email, how would
you suggest that would work? Reduce joe jobs? Maybe. Even probably. Reduce
spam? Not in the least.

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

299 Replies
484 Views

Similar Articles

12/4/2013 11:59:34 PM
page loaded in 198453 ms. (0)