Subject: RE: [Asrg] 3. Requirements - Non Spam must go through

From: "Kurt Magnusson" <[email-masked]>
Date: Thu, 10 Jul 2003 13:06:25 -0200

Phillip Hallam-Baker wrote:
>How can you return mail to the "sender" when you don't know who that is?
>
>I get tens of false bounces of mails I never sent every day. Most of the
>time it is a virus that has hijacked my address, sometimes it is spam.

Totaly correct, but there is two reasons why a spam theoretically should
be returned as undeliverable.

1. Many of todays anti-spam tools do sort valid mail as spam. Those
senders should be notefied that their mail did not get through.

2. Those spammers faking addresses on a relay, is probably unknown by
the postmaster. A lot of undelivery messages in the log might get some
attention. OK a lot of them never looks in the logs, but some might.

A practical problem with returning spam, that might be the main issue,
is that I don't want it back as undeliverable. That is why I didn´t
implemented it.

Chucks idea of changing the subject line is not a wrong idea. But if
also returned, it might further press a lazy relay postmaster to do
something. The spams get more visiable.

But since we are on the topic, in order not to get hanged by those
commercial powers, we also then need to look at the possibility that
spams with ADV: in the subject is left up to the individual ISP and/or
user to filter away. That is we need to have some rules for how to
identifying "correct" commercial mailing.  There is some RFC for ca -98
dealing with that, if I remember right.

>
>>-----Original Message-----
>>From: C. Wegrzyn
>>
........
>>the sender. I might suggest something slightly different: why
>>not have
>>it delivered and marked as SPAM in the Subject line? In this way at
>>least I can check to see if it really is spam? I'm afraid
...........
>>>Kurt Magnusson wrote:
..........
>> > I do agree with you regarding the last, we should return
>> > undeliverables, but I do not agree that we need to live > with false 
>>positives.

Kurt Magnusson

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

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

---

From: "C. Wegrzyn" <[email-masked]>
Date: Thu, 10 Jul 2003 15:12:20 -0400

I've been giving more thought to how to slow down spamming. It seems we 
should just follow 7.3 of RFC2821 - return either 250 or 252 to VRFY and 
EXPN commands.  In this way the sender can't find out if someone is 
really on a system.

Second I would kick back a 551 to every message being sent by a 
domain/user I don't recognize or wanted to reject as SPAM. In the former 
case I would send the email to the real recipient allowing them to 
decide what to do with it. I the latter case I would just toss it or 
fill in the subject with SPAM:.

Thoughts?

Chuck Wegrzyn

---

From: "C. Wegrzyn" <[email-masked]>
Date: Fri, 11 Jul 2003 06:39:20 -0400

Thoughts?

Chuck Wegrzyn

---

From: Bill Cole <[email-masked]>
Date: Fri, 11 Jul 2003 09:18:32 -0400

At 6:39 AM -0400 7/11/03, C. Wegrzyn wrote:
>I've been giving more thought to how to slow down spamming. It seems 
>we should just follow 7.3 of RFC2821 - return either 250 or 252 to 
>VRFY and EXPN commands.  In this way the sender can't find out if 
>someone is really on a system.

I don't know what sort of mail servers you work with, but the ones I 
do see insignificant amounts of VRFY and EXPN requests and already 
return the same meaningless responses for all such queries regardless 
of their arguments. This has been common practice for many years. 
RFC2821 was written to describe existing practice more than it was to 
recommend new security tactics.

>domain/user I don't recognize or wanted to reject as SPAM. In the 
>former case I would send the email to the real recipient allowing 
>them to decide what to do with it.

1. If you kick back a 5xx code of any sort to any mail, you have 
decided 'what to do with it' permanently and irrevocably.

2. Any system that generates a message to the recipient for each 
message detected as spam is at least as bad as the spam for the 
recipients behind it.

In any case, this sort of thing is well-established practice. The 
only utility I see in discussing details of response codes to various 
conditions would be to standardize them for various meanings in the 
area of spam. I may be misunderstanding the current state of 
IETF/IRTF affairs, but I think that's someone else's job. [2]

>I the latter case I would just toss it or fill in the subject with SPAM:.

Modification of existing headers by an MTA for any reason other than 
address re-writing is fundamentally wrong.[1] Adding headers (as 
SpamAssassin does) makes far more sense and prevents multiple such 
strategies from colliding with each others' efforts. There are 
certainly practical arguments for doing the conceptually wrong thing 
given the shortcomings of the world's dominant worm transmission 
vector^W^W^W desktop mail client, but it would be a bad precedent for 
an IRTF process to accommodate ephemeral and easily overcome 
shortcomings at the cost of making a 'hack' recommendation like 
subject line mangling.

[1] Many have disagreed with that exception, but between tradition 
and pragmatic concerns it is hard to really swear off that arguably 
bad habit.  I think the battle was lost when the revival of sendmail 
with v8 kept header address rewriting alive.

[2] It's also arguably not all that useful. Many sites already have 
concerns with using 5.7.x extended status codes because they reveal 
policy detail to parties believed to be malicious.

-- 
Bill Cole                                  
[email-masked]

---

From: "C. Wegrzyn" <[email-masked]>
Date: Fri, 11 Jul 2003 09:40:48 -0400

As I said in my original email I was looking for solutions to slow them 
down. You seemed to think I was suggesting examining or tightening up 
the return codes. Nothing code be further from the truth.

I do believe that we shouldn't leave a stone unturned to find answers 
for halting spam.

Chuck

Bill Cole wrote:

> In any case, this sort of thing is well-established practice. The only 
> utility I see in discussing details of response codes to various 
> area of spam. I may be misunderstanding the current state of IETF/IRTF 
> affairs, but I think that's someone else's job. [2]
>
> [1] Many have disagreed with that exception, but between tradition and 
> pragmatic concerns it is hard to really swear off that arguably bad 
> habit.  I think the battle was lost when the revival of sendmail with 
> v8 kept header address rewriting alive.
>