ietf-mta-filters
[Top] [All Lists]

Re: Comments on draft-homme-sieve-variables-01.txt

2003-04-19 03:49:59

Kjetil Torgrim Homme <kjetilho(_at_)ifi(_dot_)uio(_dot_)no> writes:

[Simon Josefsson]:

  Kjetil Torgrim Homme <kjetilho(_at_)ifi(_dot_)uio(_dot_)no> writes:
  
  > the date itself should be no more than a few minutes earlier
  > than current time.  if it isn't, there is a misconfiguration or
  > an outage going on.
  
  The time in Date: are in general not the same as delivery time.
  Differences of several hours and days are typical.

you should get a better email provider :-)

huge mailing lists may introduce a delay of half an hour.  several
hours is simply not an acceptable delay, and certainly not if it is
typical.

Moderated lists are common, and if the moderator is out of town for a
week, the Date: will be a week late.

Offline clients are also common, and the typically put the current
time of hitting the "Send" button as the Date: value (as suggested by
RFC 2822).

  What is the difference between delivery time and current time?
  
  Consider the batch example again, what would SETDATE be
  initialized to in this case?  The delivery time is in general not
  available from a RFC 2822 message, so the implementation would
  probably simply pick current time.

the latest Received header is a good bet.

Ah.  I think that should be mentioned, as one possible way to infer
the delivery time.

all right, I'm not a native speaker, but how about

   Sieve filtering should not be relied on as a security measure
   against hostile e-mail messages.  Sieve is designed to do simple,
   mostly static tests, and is not suitable for use as a spam or virus
   checker, where the perpetrator has a motivation to vary the format
   of the email in order to avoid filtering rules.

Very nice!

      For an example of a more general than expected test, consider
      looking for "xn--foo-bar" within a To: addr-spec in order to
      filter message addressed to a specific internationalized
      domain names into a separate folder, and an incoming message
      having an addr-spec of someone@(xn--foo-bar)example.org.

if you use :address for matching, this won't be a problem.  if you use
:header, there are more likely modes of failure.  e.g.,

   if :header :matches [ "To", "Cc" ] "root(_at_)*(_dot_)example(_dot_)com"

and a message with "To: root(_at_)uio(_dot_)no, 
someone(_at_)example(_dot_)com"

although this may be a common pitfall, I'm not sure warnings to "use
the appropriate test" fits in here.

IMHO it is useful if all common pitfalls that lead to security
problems are discussed.

      For an example of a less general than expected test, consider
      looking for Subject: containing "MAKE MONEY FAST" to filter
      spam into a separate folder, and an incoming message having a
      Subject: of "=?CP-1252?q?MAKE_MONEY_FAST?=.

I believe that message should be filtered just fine.

How?  Compare the following from RFC 3028.  Assuming the
implementation does not support CP-1252, I don't see how "MAKE MONEY
FAST" and "=?CP-1252?q?MAKE_MONEY_FAST?=" would match.  (The
assumption isn't a restriction, there will always be MUAs that
supports more charsets, or are less robust in their QP decoding, than
servers.)  Consider EBCDIC for a case where decoding the QP and only
using the ASCII characters would fail too.

,----
| 2.7.2.   Comparisons Across Character Sets
| 
|    All Sieve scripts are represented in UTF-8, but messages may involve
|    a number of character sets.  In order for comparisons to work across
|    character sets, implementations SHOULD implement the following
|    behavior:
| 
|       Implementations decode header charsets to UTF-8.  Two strings are
|       considered equal if their UTF-8 representations are identical.
|       Implementations should decode charsets represented in the forms
|       specified by [MIME] for both message headers and bodies.
|       Implementations must be capable of decoding US-ASCII, ISO-8859-1,
|       the ASCII subset of ISO-8859-* character sets, and UTF-8.
| 
|    If implementations fail to support the above behavior, they MUST
|    conform to the following:
| 
|       No two strings can be considered equal if one contains octets
|       greater than 127.
`----

  That reminds me, Sieve should support internationalized domain
  names by decoding them when they occur at the appropriate places
  (dot-atom's inside domain inside addr-spec, for instance).

I think that is implied, really.  it does pose a problem for clients,
they can't know whether the server supports it or not, so they need to
duplicate their tests.  hmm, perhaps we do need an extension for it.

The IDNA specification says that if IDNs are in IDN-unaware domain
name slots, it MUST be encoded as ASCII.  Since the Sieve
specification does not discuss IDN, all domain name slots in Sieve
scripts are IDN-unaware.