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

RFCs 5321 and 5322 published

Expand Messages
  • mouss
    FYI, RFCs 5321 and 5322 obsolete 2821 and 2822 (respectively).
    Message 1 of 10 , Oct 1, 2008
    • 0 Attachment
      FYI, RFCs 5321 and 5322 "obsolete" 2821 and 2822 (respectively).
    • Andrzej Kukula
      ... Again there s no mention of Delivered-To header for loop detection. Did you spot anything useful there? Regards, Andrzej Kukula
      Message 2 of 10 , Oct 1, 2008
      • 0 Attachment
        On Wed, Oct 1, 2008 at 18:29, mouss <mouss@...> wrote:
        > FYI, RFCs 5321 and 5322 "obsolete" 2821 and 2822 (respectively).

        Again there's no mention of Delivered-To header for loop detection.
        Did you spot anything useful there?

        Regards,
        Andrzej Kukula
      • mouss
        ... loop detection is not part of smtp. ... This is not the place to discuss the standards.
        Message 3 of 10 , Oct 2, 2008
        • 0 Attachment
          Andrzej Kukula wrote:
          > On Wed, Oct 1, 2008 at 18:29, mouss <mouss@...> wrote:
          >> FYI, RFCs 5321 and 5322 "obsolete" 2821 and 2822 (respectively).
          >
          > Again there's no mention of Delivered-To header for loop detection.

          loop detection is not part of smtp.

          > Did you spot anything useful there?

          This is not the place to discuss the standards.
        • Reinaldo de Carvalho
          ... Delivered to could be mentioned by the RFC, as well as Apparently-to is mentioned as should not be used . -- Reinaldo de Carvalho
          Message 4 of 10 , Oct 2, 2008
          • 0 Attachment
            On 10/2/08, mouss <mouss@...> wrote:
            > Andrzej Kukula wrote:
            >
            > > On Wed, Oct 1, 2008 at 18:29, mouss <mouss@...> wrote:
            > >
            > > > FYI, RFCs 5321 and 5322 "obsolete" 2821 and 2822 (respectively).
            > > >
            > >
            > > Again there's no mention of Delivered-To header for loop detection.
            > >
            >
            > loop detection is not part of smtp.
            >
            >
            > > Did you spot anything useful there?
            > >
            >
            > This is not the place to discuss the standards.
            >

            "Delivered to" could be mentioned by the RFC, as well as
            "Apparently-to" is mentioned as "should not be used".

            --
            Reinaldo de Carvalho
            http://korreio.sf.net
            http://python-cyrus.sf.net
          • Victor Duchovni
            ... No reason to, it has no end-to-end semantics. The only valid consumer of Delivered-To is the system that added it. The header could be:
            Message 5 of 10 , Oct 2, 2008
            • 0 Attachment
              On Thu, Oct 02, 2008 at 01:27:46PM -0300, Reinaldo de Carvalho wrote:

              > "Delivered to" could be mentioned by the RFC, as well as

              No reason to, it has no end-to-end semantics. The only valid consumer
              of "Delivered-To" is the system that added it. The header could be:

              X-Loop-COM-EXAMPLE: <date> <hmac-sha1(secret, date+address)>

              and would work just as well (or perhaps better) for loop detection.

              The point is that RFCs don't need to cover purely local issues.

              --
              Viktor.

              Disclaimer: off-list followups get on-list replies or get ignored.
              Please do not ignore the "Reply-To" header.

              To unsubscribe from the postfix-users list, visit
              http://www.postfix.org/lists.html or click the link below:
              <mailto:majordomo@...?body=unsubscribe%20postfix-users>

              If my response solves your problem, the best way to thank me is to not
              send an "it worked, thanks" follow-up. If you must respond, please put
              "It worked, thanks" in the "Subject" so I can delete these quickly.
            • Wietse Venema
              ... But it is OK to talk about changes (with respect to earlier RFCs) that affect Postfix use or development. Wietse
              Message 6 of 10 , Oct 2, 2008
              • 0 Attachment
                mouss:
                > Andrzej Kukula wrote:
                > > On Wed, Oct 1, 2008 at 18:29, mouss <mouss@...> wrote:
                > >> FYI, RFCs 5321 and 5322 "obsolete" 2821 and 2822 (respectively).
                > >
                > > Again there's no mention of Delivered-To header for loop detection.
                >
                > loop detection is not part of smtp.
                >
                > > Did you spot anything useful there?
                >
                > This is not the place to discuss the standards.

                But it is OK to talk about changes (with respect to earlier RFCs)
                that affect Postfix use or development.

                Wietse
              • Reinaldo de Carvalho
                On Thu, Oct 2, 2008 at 1:51 PM, Victor Duchovni ... Don t need but could be . The standards *could be suggest* something about loop detection. -- Reinaldo
                Message 7 of 10 , Oct 2, 2008
                • 0 Attachment
                  On Thu, Oct 2, 2008 at 1:51 PM, Victor Duchovni
                  <Victor.Duchovni@...> wrote:
                  > On Thu, Oct 02, 2008 at 01:27:46PM -0300, Reinaldo de Carvalho wrote:
                  >
                  >> "Delivered to" could be mentioned by the RFC, as well as
                  >
                  > No reason to, it has no end-to-end semantics. The only valid consumer
                  > of "Delivered-To" is the system that added it. The header could be:
                  >
                  > X-Loop-COM-EXAMPLE: <date> <hmac-sha1(secret, date+address)>
                  >
                  > and would work just as well (or perhaps better) for loop detection.
                  >
                  > The point is that RFCs don't need to cover purely local issues.
                  >
                  > --
                  > Viktor.
                  >

                  "Don't need" but "could be". The standards *could be suggest*
                  something about loop detection.

                  --
                  Reinaldo de Carvalho
                  http://korreio.sf.net
                  http://python-cyrus.sf.net
                • mouss
                  ... The situation is different. It is one thing to discourage the use of an unsafe header. it is another one to mandate (or even officially approve ) the
                  Message 8 of 10 , Oct 2, 2008
                  • 0 Attachment
                    Reinaldo de Carvalho wrote:
                    > On 10/2/08, mouss <mouss@...> wrote:
                    >> Andrzej Kukula wrote:
                    >>
                    >>> On Wed, Oct 1, 2008 at 18:29, mouss <mouss@...> wrote:
                    >>>
                    >>>> FYI, RFCs 5321 and 5322 "obsolete" 2821 and 2822 (respectively).
                    >>>>
                    >>> Again there's no mention of Delivered-To header for loop detection.
                    >>>
                    >> loop detection is not part of smtp.
                    >>
                    >>
                    >>> Did you spot anything useful there?
                    >>>
                    >> This is not the place to discuss the standards.
                    >>
                    >
                    > "Delivered to" could be mentioned by the RFC, as well as
                    > "Apparently-to" is mentioned as "should not be used".
                    >

                    The situation is different.

                    It is one thing to discourage the use of an unsafe header.

                    it is another one to "mandate" (or even "officially approve") the use of
                    Delivered-To.

                    Loop detection is easier to solve locally, and Delivered-To is one of
                    the used heuristics. but all this is too easily broken by and admin or a
                    developper (it takes one header_check to remove the said header, another
                    one to remove all Received headers, and a parameter config to change the
                    helo name. and if a proxy or a forwarder is in the path, it's even
                    easier to break things).
                  • mouss
                    ... only if you can get consensus, which is much harder than you might think. while almost everybody now agrees that putting the envelope recipient in a header
                    Message 9 of 10 , Oct 2, 2008
                    • 0 Attachment
                      Reinaldo de Carvalho wrote:
                      >
                      > "Don't need" but "could be". The standards *could be suggest*
                      > something about loop detection.
                      >

                      only if you can get consensus, which is much harder than you might
                      think. while almost everybody now agrees that putting the envelope
                      recipient in a header (except for mail delivered to a single recipient)
                      was a borked idea, there is no consensus about loop detection. (or if
                      you prefer, "Apparently-To" is ok, but given that it has already been
                      used the wrong way, it is easier to "obsolete" it rather than to give
                      100 lines explaining how/when/why to [not] use it).

                      add to this that getting consensus on smtp related drafts/rfcs is a lot
                      harder than "it should". not only because the spam and malware problem
                      makes some people think in "transient solutions" terms, but also because
                      smtp has been implemented since long, and a lot of people have different
                      ideas of what is best to do. as a result, I don't expect changes (other
                      than clarifications or esmtp extensions) in the smtp specs in the short
                      future.
                    • Matthias Andree
                      ... I wonder how useful could be (aka MAY) clauses are - if they end up being implementation-specific, not widely deployed, whatever else that is not
                      Message 10 of 10 , Oct 8, 2008
                      • 0 Attachment
                        "Reinaldo de Carvalho" <reinaldoc@...> writes:

                        > On Thu, Oct 2, 2008 at 1:51 PM, Victor Duchovni
                        > <Victor.Duchovni@...> wrote:
                        >> On Thu, Oct 02, 2008 at 01:27:46PM -0300, Reinaldo de Carvalho wrote:
                        >>
                        >>> "Delivered to" could be mentioned by the RFC, as well as
                        >>
                        >> No reason to, it has no end-to-end semantics. The only valid consumer
                        >> of "Delivered-To" is the system that added it. The header could be:
                        >>
                        >> X-Loop-COM-EXAMPLE: <date> <hmac-sha1(secret, date+address)>
                        >>
                        >> and would work just as well (or perhaps better) for loop detection.
                        >>
                        >> The point is that RFCs don't need to cover purely local issues.
                        >>
                        >> --
                        >> Viktor.
                        >>
                        >
                        > "Don't need" but "could be". The standards *could be suggest*
                        > something about loop detection.

                        I wonder how useful "could be" (aka MAY) clauses are - if they end up
                        being implementation-specific, not widely deployed, whatever else that
                        is not universal, they seem of little use to me.

                        --
                        Matthias Andree
                      Your message has been successfully submitted and would be delivered to recipients shortly.