Subject: Re: bounce, mta, & mua (was Re: sieve draft)

From: [email-masked] (Kai Henningsen)
Date: 23 Dec 1997 21:40:00 +0200

[email-masked] (Tomas Fasth)  wrote on 19.11.97 in <[email-masked]>:

> Chris Newman wrote:
>
> > This is incorrect.  UAs will have access to the "MAIL FROM" address unl
> ess
> > an upstream system violated Internet standards.  The final delivery age
> nt
> > is REQUIRED to copy the "MAIL FROM" address into the "Return-Path"
> > header.  Anything which doesn't is broken.
>
> Chris, can you give us the exact location in an RFC that backs up your
> assertion? I'm not sure it is required and I'm not sure you can ever
> rely

RFC 821, of course - this has been true as long as there has been SMTP.  
And here I thought everyone knew _that_ one ...

--- snip ---

            When the receiver-SMTP makes the "final delivery" of a
            message it inserts at the beginning of the mail data a

Postel                                                         [Page 21]


August 1982                                                      RFC 821
Simple Mail Transfer Protocol

            return path line.  The return path line preserves the
            information in the <reverse-path> from the MAIL command.
            Here, final delivery means the message leaves the SMTP
            world.  Normally, this would mean it has been delivered to
            the destination user, but in some cases it may be further
            processed and transmitted by another mail system.

               It is possible for the mailbox in the return path be
               different from the actual sender's mailbox, for example,
               if error responses are to be delivered a special error
               handling mailbox rather than the message senders.

            The preceding two paragraphs imply that the final mail data
            will begin with a  return path line, followed by one or more
            time stamp lines.  These lines will be followed by the mail
            data header and body [2].  See Example 8.

--- snip ---

If you do SMTP, and ignore RFC 821, then you're definitely seriously  
broken.

> on it's existence once the message have moved into the domain of the
> MUA.

If you don't have it at that point, then you're not in the Internet any  
more.

> If you're right, my FreeBSD "out-of-the-box" installation is certainly
> broken. The "P" flag required to generate the Return-Path header is
> _not_
> set for the local mailer by default. I don't know why, but the very
> existence of this discrepency (the fact that it's optional) is enough
> for
> me to maintain that this header might not always be available. Period.

If that's true, you should file a bug report with the FreeBSD people.  
Period.

Standards should not cater to software that is already ignoring the most  
fundamental standards in that area. That's pointless.

MfG Kai

Date: 23 Dec 1997 21:40:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Tomas Fasth)  wrote on 19.11.97 in <[email-masked]>:

> Chris Newman wrote:
>
> > This is incorrect.  UAs will have access to the "MAIL FROM" address unl
> ess
> > an upstream system violated Internet standards.  The final delivery age
> nt
> > is REQUIRED to copy the "MAIL FROM" address into the "Return-Path"
> > header.  Anything which doesn't is broken.
>
> Chris, can you give us the exact location in an RFC that backs up your
> assertion? I'm not sure it is required and I'm not sure you can ever
> rely

RFC 821, of course - this has been true as long as there has been SMTP.  
And here I thought everyone knew _that_ one ...

--- snip ---

            When the receiver-SMTP makes the "final delivery" of a
            message it inserts at the beginning of the mail data a

Postel                                                         [Page 21]


August 1982                                                      RFC 821
Simple Mail Transfer Protocol

            return path line.  The return path line preserves the
            information in the <reverse-path> from the MAIL command.
            Here, final delivery means the message leaves the SMTP
            world.  Normally, this would mean it has been delivered to
            the destination user, but in some cases it may be further
            processed and transmitted by another mail system.

               It is possible for the mailbox in the return path be
               different from the actual sender's mailbox, for example,
               if error responses are to be delivered a special error
               handling mailbox rather than the message senders.

            The preceding two paragraphs imply that the final mail data
            will begin with a  return path line, followed by one or more
            time stamp lines.  These lines will be followed by the mail
            data header and body [2].  See Example 8.

--- snip ---

If you do SMTP, and ignore RFC 821, then you're definitely seriously  
broken.

> on it's existence once the message have moved into the domain of the
> MUA.

If you don't have it at that point, then you're not in the Internet any  
more.

> If you're right, my FreeBSD "out-of-the-box" installation is certainly
> broken. The "P" flag required to generate the Return-Path header is
> _not_
> set for the local mailer by default. I don't know why, but the very
> existence of this discrepency (the fact that it's optional) is enough
> for
> me to maintain that this header might not always be available. Period.

If that's true, you should file a bug report with the FreeBSD people.  
Period.

Standards should not cater to software that is already ignoring the most  
fundamental standards in that area. That's pointless.

MfG Kai

Date: Tue, 23 Dec 97 16:12:46 +0100
From: [email-masked] (Gerben Wierda)
To: [email-masked]
Subject: Sorry, please ignore this post
Sender: [email-masked]

The traffic on this list is so low that I have been waiting for the first
message a while. I need the first message to put the list into my spamblocker
and then turn the spamblocker on again. I hope this message is sent back
to me by the list, otherwise, I hope someone posts something so I can turn
my spamblocker back on.

Sorry for the inconvenience,

--Gerben Wierda

Date: Sat, 6 Dec 1997 04:47:57 -0500 (EST)
From: Tim Showalter <[email-masked]>
To: Chris Newman <[email-masked]>
cc: MTA Filters <[email-masked]>
Subject: Re: acap, comparators, and semicolons
Sender: [email-masked]

On Sat, 6 Dec 1997, Chris Newman wrote:

> On Tue, 2 Dec 1997, Tim Showalter wrote:
> > Any suggestions?
> 
> How about just adding a comparator command, which effects all later
> searches:
> 
> Comparator "fr-ca;iso;strength=3";
> 
> This cleans up the grammar and probably does what the user wants.

This isn't too bad, but...

if header "from" contains "tjs" {
	Comparator "i;octet"
} else {
	Comparator "i;ascii-casemap"
}
# foo

By point foo, it's impossible to tell what the comparator is, and I'm not
sure I like this.

I still believe that optional arguments need some coverage in the draft or
they'll be implemented in incompatible ways when someone finally finds
something they can't hack around.

> It's a shame nobody asked for a Sieve BOF, but I suppose a 5 minute plug
> for Sieve at the Spam BOF will be good enough.

I'm hoping some interested people can get together some night, but I don't
know which night.

> P.S. I think we should stop using "-" in tokens in Sieve.  An extension
> which provided basic math operations would be useful, so "-" should be
> reserved for subtraction and negation.

Ok, that's true.  I'd still like to introduce optional arguments in some
standard way.  Luckily your argument will discourage anyone suggesting '/'
as well.

-- 
                                           Tim Showalter [email-masked]

Date: Sat, 06 Dec 1997 00:07:04 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: acap, comparators, and semicolons
To: Tim Showalter <[email-masked]>
Cc: MTA Filters <[email-masked]>
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Tue, 2 Dec 1997, Tim Showalter wrote:
> The easy remedy to this is to just put the comparator in quotes so that
> instead of being part of the keyword, it's just an argument to the command.
> There are a few other cases where optional arguments need to be used.
> 
> Any suggestions?

How about just adding a comparator command, which effects all later
searches:

Comparator "fr-ca;iso;strength=3";

This cleans up the grammar and probably does what the user wants.

People interested in the syntax for comparator naming should be at the
LESSOR BOF Monday morning at the IETF.

It's a shame nobody asked for a Sieve BOF, but I suppose a 5 minute plug
for Sieve at the Spam BOF will be good enough.

		- Chris

P.S. I think we should stop using "-" in tokens in Sieve.  An extension
which provided basic math operations would be useful, so "-" should be
reserved for subtraction and negation.

Date: Tue, 2 Dec 1997 20:54:09 -0500 (EST)
From: Tim Showalter <[email-masked]>
Reply-To: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: acap, comparators, and semicolons
Sender: [email-masked]

So the contains, is, & matches tests use ACAP's comparator registry.  ACAP
defines 3 comparators, i;octet, i;ascii-casemap, and i;ascii-numeric.

Looking at the sieve-00 implementation Rob hacked up ages ago, i;octet is
the default and i;ascii-casemap is what used to be a "-nocase" change to the
keyword.

There are two problems.  The first is that the comparator argument contains
a ; which makes the parser gross.  For the moment, I guess I'm going to
leave the "i;" part out as a hack (which is what the draft says because I
didn't read the ACAP drafts enough).

The easy remedy to this is to just put the comparator in quotes so that
instead of being part of the keyword, it's just an argument to the command.
There are a few other cases where optional arguments need to be used.

Any suggestions?

I'm considering something like

  compare-test-keywords	= "is"/"matches"/"contains"
  comparator-name	= string
  optional-comparator	= "-comparator" WSP comparator-name
  compare-test		= compare-test-keywords WSP [optional-comparator]
  header		= "header" WSP string-list WSP compare-test 
				WSP string-list

So comparator-keywords are moved out of the parser.  (Command parsing should
probably be moved out of the parser too, and resolved like symbols in a real
language.)

-- 
                                           Tim Showalter [email-masked]

Date: Mon, 1 Dec 1997 22:42:17 -0500 (EST)
From: Tim Showalter <[email-masked]>
Reply-To: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: Re: sieve: vacation extension
Sender: [email-masked]

Someone want to take on the task of writing a DSN document describing a
vacation reply?  I guess it's not a bad idea; having will-return-on-date and
other random contact information would be cool; a very smart client might
pipe such information off to a very smart addressbook program.  The vacation
draft need not reference this, but it could be nice.

SMTP level responses seem unnecessary and not that useful.  (Mail isn't a
good place to have information that seems more pertinent to something like
finger.)

Vacation should reply to the return-path, and will in the next draft.

I believe that the time for repeated messages should not be related to when
the vacation command is used.  For starters, if Sieve scripts are stored in
a filesystem, it's difficult to tell how long the vacation script has been
in effect.

So it may be useful to allow the user to clean out the vacation database on
request.  If a Sieve script is stored in ACAP, there are probably some
really easy ways to do this.

I believe vacation should be forbidden from replying to an address ending in
"-REQUEST", or perhaps "-LIST-REQUEST", but I'm not sure if this is a really
great idea or not.  (Solaris vacation has this feature.)

-- 
                                           Tim Showalter [email-masked]