Loading ...
Sorry, an error occurred while loading the content.

Re: using the character @ in the local part

Expand Messages
  • Bill Cole
    ... 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. ...
    Message 1 of 31 , Jan 3, 2013
    • 0 Attachment
      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
      <"@"@...> 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.
    • Wietse Venema
      ... Come on, don t be so naive. The backup MX scenario is an EXAMPLE of how @ in local-part can result in trouble. The same problem may happen in ANY piece of
      Message 31 of 31 , Jan 4, 2013
      • 0 Attachment
        Michael Blessenohl:
        > The security issue is, as far as I understand, that a backup MX uses an
        > @ 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?

        Come on, don't be so naive. The backup MX scenario is an EXAMPLE
        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.

        Wietse
      Your message has been successfully submitted and would be delivered to recipients shortly.