Re: how to redirect/filter bounce messages?

From: Nicolas Riendeau (no email)
Date: Wed Aug 11 2004 - 19:26:12 EDT


Hi Victor

Victor Duchovni wrote:

> The text file if not MIME encoded cannot specify its character-set,
> so this would be a separate configuration parameter:
>
> bounce_template_file = /etc/postfix/bounce_template
> bounce_template_charset = us-ascii

This is exactly what I did as I had suggested in another message in this thread

ie:

<<
> This text should also have provision for content-type and character
> set information if that is needed. It should not provide other MIME
> headers so as not to mess up the DSN message format.

Could this given as one or many main.cf parameter?

This would be done in order to avoid actually having to parse the
template file so that theys could look like this:

http://www.istop.com/~knightr/postfix/templates/bounce_fail.txt
http://www.istop.com/~knightr/postfix/templates/bounce_warn.txt
http://www.istop.com/~knightr/postfix/templates/bounce_probe.txt
>>

BTW, these are the old template files (and the last one is called
status and not probe now...).

Setting it to us-ascii is not necessary though as the charset information is not
passed when the charset value is not specified (ie empty).

These are the parameters I added :

bounce_fail_charset
bounce_fail_file
bounce_status_charset
bounce_status_file
bounce_warn_charset
bounce_warn_file

I allowed different charset values because I thought that they are not always addressed
to the same persons and as such one might want to use a different charset under some
situations (for example if one would want the fail message in more than one language, etc...).

>
> For maximal operator convenience, the code would convert codepages
> that don't subsume ASCII to utf-8, but this is largely impractical
> because many of the supported systems don't include bundled conversion
> tables for the popular charsets or a uniform safe conversion API.

And you would need to know the charset used in the template file anyway...
>
> The code could in fact reasonably support only:
>
> - us-ascii
> OR
> - iso-8859-N
> OR
> - utf-8
>
> and pessimistically assume that all other charsets are not extensions
> of ASCII and are not suitable... The list of acceptable charsets
> could be extended later as necessary.

That is indeed a possibility...

Everything else can be encoded using utf-8 right? (so even people which are using charset
differen from us-ascii and iso-8859-N could have a message in their language).

>>It is easy for Postfix to always convert the content to quoted-printable.

Wouldn't it convert it only as needed (I guess when the other server doesn't advertise
itself as supporting 8BITMIME)?

>>BUT! Unless we can find a way for Postfix to automatically supply
>>ALL MIME info, that still leaves the burden on the MTA operator to
>>worry about mind-numbing MIME details such as charset. And that is
>>not going to work.

One would hope that a MTA operator knows about these things

> I share the sentiment, but the text file alone is not enough, unless
> it includes some metadata (charset on first line?).

Makes parsing and validations more difficult to do, no?

Thanks for (both of) your input(s)!

Nick








Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD