At 10:14 AM +0000 11/27/04, Fridrik Skulason wrote:
No, they are not. They are a critically important part of the
robustness of email. Broad acceptance of the idea that bounces are
evil will be the last nail in the coffin of email.
Bounces are useful if they go to the person who actually sent the mail.
Those "bounces" do not - they go to an innocent bystander. Whether this
is due to inherent flaws in the SMTP protocol, sloppy management or
incorrect configuration is arguable - but the fact is that those bounces
are making the problem worse and they NEED to be eliminated.
On that we agree: bounces should never be the result of some system
deeming the bounced mail to be in some class that is typically
malicious or deceptive, i.e. spam of any variety including Microsoft
OS worm spam.
Uh, have you heard of Swen???
Swen is NOT an example of the behaviour being discussed.
Here was the specific context to which I was responding:
they might even send out email using the user's own email
account and/or email client.
Swen does that. Really.
Most worms
harvest e-mail addresses from the infected machine, and typically
select one of them at random as the sender. This can of course result
in the worm sending itself out as being from the "actual" owner of the
machine - however, usually this is not the case. Swen typically
pretended to be from "MS Technical Support" or something like that.
Only in the headers. The SMTP envelope of a Swen message is
consistently the address configured into Outlook Express on the
infected system, and the mail travels through the configured outbound
mail server. This is reliable enough that Swen will break on systems
where those configurations don't work.
As far as I know, there is not a single worm in the wild that searches
for the "real" owner of the infected machine and *only* uses that. I
expect that practice to become more common in the future, as one way
of avoiding SPF checking, but currently this is simply not the case.
Keep in mind that SPF has nothing to do with headers, and is solely
for SMTP envelope checking. I still see a trickle of Swen even though
I shun machines transporting it, and SPF does nothing at all to stop
it.
For example, here's the latest Swen I have where the envelope sender
domain had an SPF record:
Return-Path: js(_dot_)bennett(_at_)ntlworld(_dot_)com
Received: from mta05-winn.mailhost.ntl.com ([212.250.162.8] verified)
by sc1.scconsult.com (Stalker SMTP Server 1.8b9d14)
with ESMTP id S.0000707800 for <bill(_at_)scconsult(_dot_)com>; Mon, 15 Nov
2004 12:19:11 -0500
Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8])
by mta05-winn.mailhost.ntl.com with ESMTP
id
<20041115171908(_dot_)TIIG3998(_dot_)mta05-winn(_dot_)mailhost(_dot_)ntl(_dot_)com(_at_)aamta04-winn(_dot_)mailhost(_dot_)ntl(_dot_)com>;
Mon, 15 Nov 2004 17:19:08 +0000
Received: from itmup ([62.255.124.16]) by aamta04-winn.mailhost.ntl.com
with SMTP
id
<20041115171835(_dot_)PROX6712(_dot_)aamta04-winn(_dot_)mailhost(_dot_)ntl(_dot_)com(_at_)itmup>;
Mon, 15 Nov 2004 17:18:35 +0000
FROM: "Network Message Storage Service" <kmailform(_at_)bigfoot(_dot_)com>
TO: "inet client" <user(_at_)mxserver(_dot_)com>
SUBJECT:
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="qielpyeqr"
Message-Id:
<20041115171835(_dot_)PROX6712(_dot_)aamta04-winn(_dot_)mailhost(_dot_)ntl(_dot_)com(_at_)itmup>
Date: Mon, 15 Nov 2004 17:19:08 +0000
The relevant SPF record:
ntlworld.com. 43200 IN TXT "v=spf1
ip4:212.250.162.0/26 ip4:62.253.162.0/24 ?all"
--
Bill Cole
bill(_at_)scconsult(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg