|
|
Date: Prev Next Date Index Thread: Prev Next Thread Index
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Martin Zahn wrote: | 8-Bit Header Data (e.g. Reply-Address: "hans.müller" instead of | "hans.mueller") should be allowed from amavisd and should not be | marked as BAD-HEADER. | | As much as I know, domain names can now include Unicode data | like "müller.ch". [snip] | From my point of view, it would be helpful, if the User can | switch such 8-Bit / Unicode test in the header on/off. Today | only the whole Headertest can be switched on/off. RFC 2822 explicitly forbids 8-bit characters in SMTP mail headers. However, your mail client and/or mail server *can* use the encoding protocols specified in RFC 2047 to encode/decode 8-bit characters at both ends of the transmission. In other words, your mail server needs to be configured to perform RFC 2047 encoding, so that your 8-bit characters get encoded properly before submitting them to another MTA via SMTP. Likewise, your mail server needs to decode these 8-bit characters in mail that you receive. During the SMTP portion of the transmission, though, the mail *must* be 7-bit. ~ e.g. sender (8-bit) --> SMTP (7-bit) --> receiver (8-bit) If your mail server is configured to perform RFC 2047 encoding/decoding, your 8-bit headers should be properly encoded to 7-bits for the SMTP transmission, and then decoded to 8-bits again at the receiving end. By doing this, you avoid the "bad header" filter, and make everyone happy :) - -- Robert LeBlanc <rjl-fBBSUI5vRLiWd6l5hS35sQ@xxxxxxxxxxxxxxxx> Renaissoft, Inc. Maia Mailguard <http://www.maiamailguard.com/> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCA11gGmqOER2NHewRAvYDAJ9NbgvvYNLaOP5JzkhcfilsdT+I2gCgjM1W bjhvDPWJwHLoVy6lIhZ4J5Q= =mglH -----END PGP SIGNATURE-----
Thread at a glance:
Previous Message by Date:Re: Can't remove an item from the whitelist-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Squyres wrote: | Any further insight on this? | | I still have this problem (can't remove entries from the whitelist); I'm | happy to provide any additional information, but have zero clue where to | look or what additional information you're looking for. You've discovered a bug, presumably. Is it reproduceable, or a mysterious one-time fluke? - -- Robert LeBlanc <rjl-fBBSUI5vRLiWd6l5hS35sQ@xxxxxxxxxxxxxxxx> Renaissoft, Inc. Maia Mailguard <http://www.maiamailguard.com/> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCA1gpGmqOER2NHewRAuYcAKCB4NgOpgDutuNpv2HZfeNj8zTQ7QCfQEly vNO87DLvhOi42mgeEu1hYzc= =kpwL -----END PGP SIGNATURE----- Next Message by Date:Re: Suggestion: Exclude Patterns from user auto-creation-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Schilling wrote: | 4. So the result of my thinking is, that it would be nice to implement a | Blacklist for user-autocreation in maia. If a new account should be | created it should be checked against this blacklist. The blacklist | contains text-entries or regular expressions. So I can blacklist | everything to "confixx-*". With this option, the user-autocreation is | denied for the alias-adresses but not for the real user accounts. There | are several other cases, where user-auto-creation should be denied, but | generelly it should be allowed. Technically this exists already in the form of an undocumented feature in amavisd-maia. There is a setting you can use in amavisd.conf called $no_autocreate_domains_re, which obeys the same syntax as the old $local_domains_re regex. If it's defined, amavisd-maia will read that regex to look for patterns it should use as exceptions to the user-autocreation policy. This was intended originally as a means of excluding certain domains from user-autocreation, but it works just as well for specific e-mail addresses, since it matches its patterns against the entire e-mail address. This feature, as I mention, has not been properly documented, and I believe only one or two people have actually used it, quite some time ago, so it hasn't received a lot of testing. - -- Robert LeBlanc <rjl-fBBSUI5vRLiWd6l5hS35sQ@xxxxxxxxxxxxxxxx> Renaissoft, Inc. Maia Mailguard <http://www.maiamailguard.com/> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCA18GGmqOER2NHewRAmCuAKCnstP/E/PTwY5AWNEE23+8kam6dwCfRh5l Za6eIoi+8tAjxzxbW2zqRaA= =xsPi -----END PGP SIGNATURE----- Previous Message by Thread:Re: Can't remove an item from the whitelist-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Squyres wrote: | Any further insight on this? | | I still have this problem (can't remove entries from the whitelist); I'm | happy to provide any additional information, but have zero clue where to | look or what additional information you're looking for. You've discovered a bug, presumably. Is it reproduceable, or a mysterious one-time fluke? - -- Robert LeBlanc <rjl-fBBSUI5vRLiWd6l5hS35sQ@xxxxxxxxxxxxxxxx> Renaissoft, Inc. Maia Mailguard <http://www.maiamailguard.com/> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCA1gpGmqOER2NHewRAuYcAKCB4NgOpgDutuNpv2HZfeNj8zTQ7QCfQEly vNO87DLvhOi42mgeEu1hYzc= =kpwL -----END PGP SIGNATURE----- Next Message by Thread:Re: Suggestion: Exclude Patterns from user auto-creation-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Schilling wrote: | 4. So the result of my thinking is, that it would be nice to implement a | Blacklist for user-autocreation in maia. If a new account should be | created it should be checked against this blacklist. The blacklist | contains text-entries or regular expressions. So I can blacklist | everything to "confixx-*". With this option, the user-autocreation is | denied for the alias-adresses but not for the real user accounts. There | are several other cases, where user-auto-creation should be denied, but | generelly it should be allowed. Technically this exists already in the form of an undocumented feature in amavisd-maia. There is a setting you can use in amavisd.conf called $no_autocreate_domains_re, which obeys the same syntax as the old $local_domains_re regex. If it's defined, amavisd-maia will read that regex to look for patterns it should use as exceptions to the user-autocreation policy. This was intended originally as a means of excluding certain domains from user-autocreation, but it works just as well for specific e-mail addresses, since it matches its patterns against the entire e-mail address. This feature, as I mention, has not been properly documented, and I believe only one or two people have actually used it, quite some time ago, so it hasn't received a lot of testing. - -- Robert LeBlanc <rjl-fBBSUI5vRLiWd6l5hS35sQ@xxxxxxxxxxxxxxxx> Renaissoft, Inc. Maia Mailguard <http://www.maiamailguard.com/> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCA18GGmqOER2NHewRAmCuAKCnstP/E/PTwY5AWNEE23+8kam6dwCfRh5l Za6eIoi+8tAjxzxbW2zqRaA= =xsPi -----END PGP SIGNATURE-----
|
|
