search for: rfc2047

...Subject line: if not exists ["List-Id", "List-Post"] { vacation :days 7 :addresses ["test at netcologne.de"] :subject "=?utf-8?b?w4TDlsOc?= sadasd" "Bin gerade nicht hier."; } As you can see, the Subject is already MIME encoded according to RFC2047. Starting with sieve 0.1.14 the subject is now encoded by sieve again, so I get the following in my vacation mail: Subject: =?utf-8?q?=3D=3Futf-8=3Fb=3Fw4TDlsOc=3F=3D?= sadasd As you can see, the RFC2047 encoding is RFC2047 encoded, which results in an unreadable subject. According to RFC5230 s...

...arset issues properly. IETF draft says: 4.3. Subject and From Parameters The ":subject" parameter specifies a subject line to attach to any vacation response that is generated. UTF-8 characters can be used in the string argument; implementations MUST convert the string to [RFC2047] encoded words if and only if non-ASCII characters are present. Implementations MUST generate an appropriate default subject line as specified below if no :subject parameter is specified. (see http://tools.ietf.org/html/draft-ietf-sieve-vacation-07) The problem is that the dovecot plugi...

I have setup Dovecot-1.2 'delivery' to use Dovecot's Sieve as well (both versions are latest from dovecot.org). I am curious if sieve can handle Japanese, or locale, in general in the language. In particular, the subject which is encoded even more complicated. if header :contains "subject" ["test", "???"] { So if I want to file based on above, test,

Folks, I'm using a Sieve script for vacation messages and there's something strange with it in certain cases. The script uses the "variables" extension to produce the "Re: [original subject] (autoreply)" subject line for the vacation message. All is well except for cases when that [original subject] is written in Russian. In those cases the subject string is

...me parts in this situation to remove the ?= =?. I'm not sure if an IMAP client should know to combine the parts in their current format. FWIW I see that Courier does the same as Dovecot in this situation. I think the 'alternative' method of splitting filenames I'm raising breaks RFC2047 (details below), but unfortunately this method is used by some large email generators like gmail - also details below. Key bits from RFC2047 section 5 part (3) re. only a single encoded-word ('phrase') being allowed for a MIME Content-Type / Content-Disposition: phrase = 1*( encoded-wo...

...me parts in this situation to remove the ?= =?. I'm not sure if an IMAP client should know to combine the parts in their current format. FWIW I see that Courier does the same as Dovecot in this situation. I think the 'alternative' method of splitting filenames I'm raising breaks RFC2047 (details below), but unfortunately this method is used by some large email generators like gmail - also details below. Key bits from RFC2047 section 5 part (3) re. only a single encoded-word ('phrase') being allowed for a MIME Content-Type / Content-Disposition: phrase = 1*( encoded-wo...

Hi, hi, hi little droogies First of all, sorry for the lame english and the dumb question. After a quick search on google I found iconv, and some other toys, but the point is: I''m making a small webmail app for my company, still taking the first steps. For instance, if I want to read my INBOX folder and list the messages: ------------------------------------------- CONTROLLER =>

...ems that global state info would cause for Dovecot v2.0, but it is also important for v1.2 as it significantly cleans up the library implementation. + Made LDA Sieve plugin recognize the deliver_log_format setting. + Message headers produced from user-supplied data are now RFC2047-encoded if necessary for outgoing messages. This is for example important for the :subject argument of the vacation action. + Added support for the $text$ substitution in the deprecated notify extension. + The subaddress extension now also accepts recipient_delimiter setting as...

...ems that global state info would cause for Dovecot v2.0, but it is also important for v1.2 as it significantly cleans up the library implementation. + Made LDA Sieve plugin recognize the deliver_log_format setting. + Message headers produced from user-supplied data are now RFC2047-encoded if necessary for outgoing messages. This is for example important for the :subject argument of the vacation action. + Added support for the $text$ substitution in the deprecated notify extension. + The subaddress extension now also accepts recipient_delimiter setting as...

Hello list, I have noticed that sieve vacation action breaks some non-english letters in the subject. I tested with russian language, if subject contains letters from specific diapason russian alphabet, the message received with unreadable subject, but text in the body with the same letters looks ok. Here is example of full subject header, it contains russian alphabet: Subject:

...oftware. The specific mail protocol error in the original message is as follows: ----------------------------------------------------------------------------- The mail headers in the following message contain 8-bit text, which is prohibited by RFC 2047. See <URL:ftp://ftp.isi.edu/in-notes/rfc2047.txt> for more information. ----------------------------------------------------------------------------- -------------- next part -------------- Received: from mms ([::ffff:172.16.1.13]) by mail with esmtp; Sun, 23 Jan 2005 17:24:41 -0800 Received: from 8.166.199.248 by ; Mon, 24 Jan 2005 05:2...

I've found a much better solution; it's standard (in Unicode itself), simple and more flexible: Unicode language tagging. It was made for just this purpose, in fact. A technical description is at http://www.unicode.org/unicode/reports/tr27/#tag which, like all specs, makes it sound a bit more complicated than it really is. It comes down to this: mark the language of text with U+E0001

I've read through what I think is the entire thread and looked at the standard in its current incarnation (https://reactor-core.org/~djw/ogg-tags.txt). I have only one major problem with the proposed standard at the moment. The existance of both PERFORMER and ENSEMBLE tags. I think this is describing the same type of data (ENSEMBLE = thing that performed the music, PERFORMER = thing that

I've read through what I think is the entire thread and looked at the standard in its current incarnation (https://reactor-core.org/~djw/ogg-tags.txt). I have only one major problem with the proposed standard at the moment. The existance of both PERFORMER and ENSEMBLE tags. I think this is describing the same type of data (ENSEMBLE = thing that performed the music, PERFORMER = thing that

...? ldstedt Sund <erikalds at interagon.com>' > submitter 364809 David H?rdeman <david at hardeman.nu> Bug #364809 [bsd-mailx] mailx: mail sends 8bit characters in headers - was: bts sends 8bit characters in headers Bug #207724 [bsd-mailx] mailx: please encode headers according to RFC2047 Bug #282534 [bsd-mailx] logcheck: No contents' charset specified Bug #675914 [bsd-mailx] devscripts: [pts-subscribe] does not correctly encode 8-bit characters in From header of sent mail Changed Bug submitter to 'David H?rdeman <david at hardeman.nu>' from 'David H??rdeman &l...