On 3 Jan 2013, at 18:33, Michael Blessenohl wrote:
Am 04.01.2013 00:16, schrieb Stan Hoeppner:
On 1/3/2013 4:59 PM, Michael Blessenohl wrote:
Thanks a lot for the help. There is no firewall messing with SMTP
inbetween. With both options
resolve_dequoted_address = no
allow_untrusted_routing = yes
it finally works. Because I don't have a backup MX, this set-up
should
be fairly safe to use.
Why are you so committed/determined to use special characters in the
local-part, especially after the experts explained you should not be
doing so? You obviously "need" to use '@' in local-part. Why do you
need to do this?
Well I don't need it.
Then you should not depend on other software supporting it, or even
expect such support to be the norm. RFC5321 and its ancestors make that
clear.
I just spent some time to write code compatible with the RFC. I think
it'd be sad if postfix would be the 'weak link' in the chain.
And I have a 'bad' habit of doing things thoroughly.
Perhaps reading RFC5321, its ancestors, and its references would be a
good place to start practicing that "habit." Specifically, the "SHOULD"
admonition on p42 of RFC 5321 (Sec. 4.1.2) and the definition of
"SHOULD" for RFC's referenced on p6 (Sec. 1.3).
In the real world of email, the quoted-string syntax for email
local-parts is widely broken by MTAs, MUAs, and a variety of adjunct
tools like spam filters. It is an artifact of ancient email history
which was a bad idea when first specified and has lost support in
software over time rather than gained it. The known risk of making
Postfix tolerate this antique bad idea is a very tiny part of a broad
universe of more obscure potential risks from passing around widely
unanticipated strings as email local-parts between sites & software that
may or may not handle them carefully. Because of the potential trouble
from handling local-parts with opaque embedded routing, metacharacter,
and quoting/escaping structures, many mail systems intentionally won't
handle quoted-string local-parts in strictly correct ways or at all, so
attempts to use them with especially problematic characters like @ are
likely to fail. Reconfiguring the local MTA to not choke on
<"@"@example.com> is something you can do to hide the problem from
yourself, but it doesn't solve the practical problem of such addresses
being most likely an attack attempt of some sort aimed at a remote site
rather than legitimate. If you try to be as lenient as formally possible
in validating local-parts you are likely to make your software a conduit
for malicious activity without getting any practical benefit.
If you are doing input validation on email addresses, it is no
unreasonable in the modern world to reject use of the quoted-string
construct and only accept unquoted forms. A mailbox that can only be
mailed using a quoted-string address is not a functional mailbox in the
modern world.
