Re: using the character @ in the local part
- On 3 Jan 2013, at 18:33, Michael Blessenohl wrote:
> Am 04.01.2013 00:16, schrieb Stan Hoeppner:Then you should not depend on other software supporting it, or even
>> 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
>>> 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.
expect such support to be the norm. RFC5321 and its ancestors make that
> I just spent some time to write code compatible with the RFC. I thinkPerhaps reading RFC5321, its ancestors, and its references would be a
> it'd be sad if postfix would be the 'weak link' in the chain.
> And I have a 'bad' habit of doing things thoroughly.
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
<"@"@...> 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
- Michael Blessenohl:
> The security issue is, as far as I understand, that a backup MX uses anCome on, don't be so naive. The backup MX scenario is an EXAMPLE
> @ in the local part for internal purposes. Which, in theory, can be
> exploited to use the server as open relay. As long as I don't use a
> backup MX, I don't have an open relay and everything is fine, isn't it?
of how @ in local-part can result in trouble. The same problem may
happen in ANY piece of software that decisions based on the content
of an email address.