Subject: Re: [Asrg] Spammer responses to SPF

From: Scott Nelson <[email-masked]>
Date: Mon, 16 Jun 2003 15:04:47 -0700

At 04:33 PM 6/16/03 +0200, Markus Stumpf wrote:
>On Sat, Jun 14, 2003 at 01:58:58AM -0400, Meng Weng Wong wrote:
>> On Fri, Jun 13, 2003 at 05:54:55PM -0400, Barry Shein wrote:
>> | 
>> | It's not like spammers can't change their behavior, they often do, and
>> | this one isn't even hard to change.
>> 
>> I agree; we must play good chess.  If SPF/DMP/RMX/... goes in, what do
>> you think the spammers will do next?
>
>spammers will switch back to empty envelope senders.
>Then all people will start to block bounces.
>This causes the eMail-system to become totally unreliable.
>

[Note - this is an opinion piece with little or no hard data.]

I don't think so.  First, only people who don't understand what
empty envelope sender means will block them all.  
I'm guessing that's a majority of the end users,
but not a significant fraction of the people who make the
mail system work.
Spam with an empty envelope isn't ever going to be effective, 
since most will filter it out.  Also, more effective blocking
of "empties" that aren't DSNs is possible.  We just don't do it
(yet) because there isn't much call for it.   For example,
only accepting a standardized bounce (i.e. one following RFC 1894) 
would stop most of the spam but only a tiny fraction of the real DSNs.
The second round of this is spam that really looks like an RFC 1894 DSN.
That leads to DSNs including tokens from the original messages.
(identifiable message-ids)  I don't think there's
a third round - they can't go further, and the damage caused
is limited to that state.  So we lose some reliability
(because a few real DSNs will be discarded) but we'd still have
enough to keep the system mostly reliable.

Does that mean I think spammers won't use empty envelopes?

No.

"Spammers" is not a single entity.  It's possible that even single
spammers will try many different approaches, but certainly as
group, they will try almost everything they can think of.
Thus, they won't switch to empty envelopes, they'll do 
empty envelopes /as well/.  Or rather, some will do empty envelopes,
while some will continue to forge envelopes, and some will buy 
dozens of new domains to spam "from".

This may seem a trivial distinction, but I think it's important.
We aren't facing an enemy army, with a cohesive leadership, 
it's more like a thousand guerrillas.

Scott Nelson <[email-masked]>

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 17 Jun 2003 13:09:37 +0200

> but not a significant fraction of the people who make the

*lol*
Have you ever been on a MTA mailing list?
There are some ten messages a week "how can I block <> for MTA xyz".
I see about 30-40 each day that generate double bounces because "empty
senders are not allowed".

> would stop most of the spam but only a tiny fraction of the real DSNs.

How about all the "robots" or CR systems that send their mails with
empty envelope senders, because they don't want an answer if the
challenge was faked. How about all the autoresponders?
There are lots of valid emails with empty envelopes.

> enough to keep the system mostly reliable.

Sorry, I don't think it's reliable if bounces get lost. Just like
discarding spam qualified emails automatically is .. hmmm .. unwise,
because if it's a false classification the sender has no chance to get
informed what happend. At times where email is considered a trustworthy
medium this is unacceptable.

> it's more like a thousand guerrillas.

And I surely don't stop aguing that a TXT record with the contents
"MAILSERVER" in reverse DNS would be much faster and easier deployed
and effective than RMX or companions. And it would save us from
accepting email from all the broken workstations, homecomputers, open
proxies and virus infected hosts that never had been intended to be a
mailserver.

And I yet have to see that RMX or companions save us from the problem
to order some hundred 9nerauhi3250780asd.com type domains, use short
TTLs (5-10 seconds) and add RMX records for the open relays that are
abused right now. The next thing surely will be that TTLs < 86400 for
RMX records are forbidden ...

Yeah I know, reverse DNS is lame.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Steven F Siirila <[email-masked]>
Date: Tue, 17 Jun 2003 13:29:13 -0500

On Tue, Jun 17, 2003 at 01:09:37PM +0200, Markus Stumpf wrote:
	.
	.
	.
> proxies and virus infected hosts that never had been intended to be a

Amen!  This is similar to what we'd like to see.  We are presently
requiring reverse DNS for IP addresses of MTA's which connect to our MX
(with exceptions, which are dwindling).  This has nothing to do with the
MAIL FROM domain, it simply means that if you connect to us, your IP address
must have a name, and that name must map back to your IP address.  What you
suggest above is exactly the sort of next step we're looking for; namely,
a DNS RR which tells the world that a particular host name has been designated
as an MTA (outgoing at least).  I would suggest something like:

myhost.mydomain.com.	MTA	"[email-masked]"

This also requires you to specify an abuse address for that MTA.
Since this does introduce another RR, a TXT record could be recognized as well:

myhost.mydomain.com.	TXT	"MTA:[email-masked]"

Unlike other proposals, this one does not relate the MAIL FROM domain with
the connecting IP or the HELO line.  It simply states that the host name in
question is in fact intended to be an MTA.

Reverse DNS, when applied to vast portions of the Internet, has allowed us
to cut down on spam signifigantly.  The key to implementing this for us was
the ability to include a URL in SMTP 550 error messages directing the user
to a web site explaining why they were blocked and how to resolve.