Subject: Is this filterable?

From: Gerben Wierda <[email-masked]>
Date: Tue, 30 Jun 98 15:35:38 +0200

I know most people on this list are busy with implementation of filtering  
stuff, but I was wondering: suppose I have a filter, would it be possible to  
filter on spoofing of internal e-mail addresses in the From: header?

The From: header is a good candidate for some kind of filtering. But what  
if spammers put my own e-mail address in the From: header (and thus spam by  
sending one message per SMTP job)? Would there be some way for me to  
recognize that this is an outside message, even if it says it is internal?  
Message-ID can be spoofed also. So I am currently left with the idea that  
only the Received: headers added by intermediaries are a possible source for  
detecting spoofing.

But how would I write rules for filtering that out? What kind of  
combination of internal addresses (consider a complete domain) and Received:  
headers would do the job?

And supposed I have such a rule, how would I prevent messages that I resend  
(from my domain to another and back, those get a load of extra Received  
headers but keep the original From:)?

Thanks,

--
[email-masked] (Gerben Wierda)
"If you don't know where you're going, any road will take you there"
Paraphrased in Alice in Wonderland, originally from the Talmud.

Dass man fuer die Philosophie ein Interesse zeigt, bezeugt noch keine
Bereitschaft zum Denken -- Martin Heidegger

---

From: Ned Freed <[email-masked]>
Date: Tue, 30 Jun 1998 09:39:55 -0700 (PDT)

> sending one message per SMTP job)?

What if they do? We all know that mail headers are easily forged.

> Would there be some way for me to

Generally speaking the answer is no, it is not possible. For example, I assume
you are on the mta-filtering list. This then means that when you posted a
message to the list you then received a message from the list -- from outside
your domain -- with your address in the From: field. But this is perfectly
legitimate mail you want to receive.

And in any case, this is not within scope of the task at hand. The task
at hand is to define a filtering language. And yes, this language acts
on material which, in general, cannot be trusted to be reliable. And
yes, this means that filters, once established, can, once spammers understand
how they work, be circumvented in most if not all cases. It is a simple
question of entropy, really, and nothing ever wins against entropy.

But this doesn't mean filters aren't useful. They are. For one thing, they can
be used to lots of things other than blocking spam. And for another, most
spammers do leave telltales (perhaps not in the From: header but somewhere)
that can be used as triggers to block spam reception. Such schemes have
to be revised regularly to be effective, but one of the goals here is to
provide a language that makes such revisision convenient.

> only the Received: headers added by intermediaries are a possible source for

Even this doesn't work, as my example above shows.

If you want to detect other people using your address to send messages you did
not write you should be signing all your messages.

> headers would do the job?

It's a pointless question since route-based checks rarely, if ever, work all
that well.

> headers but keep the original From:)?

Well, you can simply avoid doing this sort of resending if you want. But
mailing lists and their characteristics cannot be avoided.

				Ned

Date: Tue, 30 Jun 1998 09:39:55 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Is this filterable?
To: Gerben Wierda <[email-masked]>
Cc: MTA Filters List <[email-masked]>
Sender: [email-masked]

> sending one message per SMTP job)?

What if they do? We all know that mail headers are easily forged.

> Would there be some way for me to

Generally speaking the answer is no, it is not possible. For example, I assume
you are on the mta-filtering list. This then means that when you posted a
message to the list you then received a message from the list -- from outside
your domain -- with your address in the From: field. But this is perfectly
legitimate mail you want to receive.

And in any case, this is not within scope of the task at hand. The task
at hand is to define a filtering language. And yes, this language acts
on material which, in general, cannot be trusted to be reliable. And
yes, this means that filters, once established, can, once spammers understand
how they work, be circumvented in most if not all cases. It is a simple
question of entropy, really, and nothing ever wins against entropy.

But this doesn't mean filters aren't useful. They are. For one thing, they can
be used to lots of things other than blocking spam. And for another, most
spammers do leave telltales (perhaps not in the From: header but somewhere)
that can be used as triggers to block spam reception. Such schemes have
to be revised regularly to be effective, but one of the goals here is to
provide a language that makes such revisision convenient.

> only the Received: headers added by intermediaries are a possible source for

Even this doesn't work, as my example above shows.

If you want to detect other people using your address to send messages you did
not write you should be signing all your messages.

> headers would do the job?

It's a pointless question since route-based checks rarely, if ever, work all
that well.

> headers but keep the original From:)?

Well, you can simply avoid doing this sort of resending if you want. But
mailing lists and their characteristics cannot be avoided.

				Ned

From: Gerben Wierda <[email-masked]>
Date: Tue, 30 Jun 98 15:35:38 +0200
To: MTA Filters List <[email-masked]>
Subject: Is this filterable?
Sender: [email-masked]

Thanks,

Date: Wed, 10 Jun 1998 17:13:10 -0700
To: Matthew Wall <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Chicago IETF: To Meet or Not to Meet
Cc: MTA Filters List <[email-masked]>, Ned Freed <[email-masked]>
Sender: [email-masked]

I agree: no BOF for Chicago.

(I have an implementation of the current draft, by the way.)

Date: Wed, 10 Jun 1998 13:01:27 -0400
From: Matthew Wall <[email-masked]>
To: MTA Filters List <[email-masked]>
cc: Ned Freed <[email-masked]>
Subject: Chicago IETF: To Meet or Not to Meet
Sender: [email-masked]

Howdy,

just got the call for scheduling WG/BOF meetings for the Chicago IETF today
from Marcia.

My inclination is to NOT schedule a BOF at Chicago. Here's my reasoning:

- the pushback from the meeting at LA was that there was plenty of interest,
but before proceeding, the rough edges had to be worked out and a revised
version of the spec worked out on the list.

As we've had only about 20 posts to the list since the LA BOF, I think we
have a lot more work to do on the list.

FYI, the official (blue sheet) attendance at the BOF was 87, though I
head-counted about 100.

- my personal feeling on this is we should "finish" SIEVE more or less as is
as "SIEVE1" without opening up ratholes like procedures, and use that --
which will provide some working solutions now, especially since a couple of
folks are already doing implementations -- and provide a basis of discussion
for standardization and additional work. There's nothing in "SIEVE1" as-is
that can't be undone in an enhanced "SIEVE2". This method of proceeding
doesn't require a meeting at this point, since I don't think we've seen
enough progress since LA at this point to justify a productive meeting. And
I'd prefer holding off Ratholefestapalooza II until we have working
experience with simplified SIEVE1-style implementations. Just my druthers,
but I will defend the position that simple and implemented is better than
complicated and vapor.

- remember that official IETF procedures allow only _two_
officially-scheduled BOFs. I'd like to reserve that last BOF for December
(or some later use), at which point we can (a) go straight to standard or
(b) decide to go ahead with a working group (or c, abandon all work 8-). I
basically don't want to "waste" our second and last official BOF without
more evidence that we'll have sufficient implementation progress by August,
and similarly, with sufficient implementation progress it will become a lot
more apparent whether this puppy has enough momentum to go formal WG route
and/or enough simplicity to skip it and go straight to proposed.

- I personally have next to no time to put into organizing a SIEVE BOF for
August, especially if a couple of other expected IETF obligations percolate
up for that meeting.

- all that said, the December meeting isn't too far off, so I don't think
delaying a BOF or a putative WG session until then is terribly harmful.

Comments/reactions...?

We have until August 3 to request a slot, but I'd like to develop a
yes/no/punt consensus now if at all possible. 

- Matt

Date: Wed, 3 Jun 1998 11:29:19 -0700 (PDT)
From: Eric Horst <[email-masked]>
To: MTA Filters List <[email-masked]>
Subject: mailstore independence
Sender: [email-masked]

I've been thinking about filtering for some time but not been following
the Sieve discussions.  Hopefully I've read enough of the archive to not
sound like a total schmuck. 

After reading the -03 draft my issue is with "fileinto".  I don't think
the description of fileinto is as independent of mail architecture as it
could be.  The main issue is the wording "drops the message in to a named
folder."  While this are general terms they do carry some baggage.  
Rather than attempt a discussion I'll give a counter proposal:

    Syntax:      fileinto <location>

    The "fileinto" action inserts the mesage into the mail store at the
    specified location.

This avoids the loaded terms and hints of a specific implementation.  By
contrast I should point out that "keep" is quite nicely defined avoiding
these pitfalls.

Likewise, I think that any places in the draft that use the wording "the
message would be filed into INBOX" (notably in the examples for "replay"
and "support") should be rewritten as "the message would be filed into the
default location."  Even though they are examples "INBOX" brings some
baggage into the spec.

Hopefully this is productive.

--Eric