Disposition-notification-to header

[zharpaz-bmc-com]

Hi Philip,

Looking at the headers of the message, I do not see the "Disposition-notification-to=[email protected]" header. I thought it should be included in the message to signal that an MDN is required.

Thanks,
Ziv

[phax]

Indeed it is. But it must be part of the partnership.
It is applied here: https://github.com/phax/as2-lib/blob/master/as2-lib/src/main/java/com/helger/as2lib/processor/sender/AS2SenderModule.java#L446

hth, Philip

[zharpaz-bmc-com]

I see. What about the option of working synchronously, but not asking for MDN?

Thanks,
Ziv

[phax]

If you mean you don't want an MDN - just do not send the header. As you can see in the code - if the partnership does not have the property, that header is not send, and no MDN is requested.
If you want an async MDN, add more headers.

[zharpaz-bmc-com]

Hi,
when a message does not contain "Disposition-notification-to", and does contain the header "Disposition-Notification-Options", the server does return an MDN. (com.helger.as2lib.message.AS2Message#isRequestingMDN, line 106).
Does it conform to the standard?
(if I do not send it, I get the error 'The value of 'DigestAlgorithm' may not be null').

Thanks for your help,
Ziv

[phax]

Well according to chapter 2 of https://www.ietf.org/rfc/rfc3798.txt:

Message disposition notifications are requested by including a
Disposition-Notification-To header in the message. Further
information to be used by the recipient's MUA in generating the MDN
may be provided by also including Original-Recipient and/or
Disposition-Notification-Options headers in the message.
-> that would indicate that my implementation is incorrect.

I also didn't find any reference in RFC 4130. Any objections on deleting these checks?

[zharpaz-bmc-com]

My understanding from the RFC is that if the header Disposition-Notification-To does not exist, an MDN should not be returned. Currently the server returns an MDN when Disposition-Notification-Options exists. The result is that I cannot make the client generate a message that does not receive an MDN (without asynchronous reply). From: Philip Helger [mailto:[email protected]] Sent: Fri-29-Jun-18 17:27 To: phax/as2-lib <[email protected]> Cc: Harpaz, Ziv <[email protected]>; Author <[email protected]> Subject: Re: [phax/as2-lib] Disposition-notification-to header (#42) Well according to chapter 2 of https://www.ietf.org/rfc/rfc3798.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfc_rfc3798.txt&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=jXF8HD16qCr9zl7f4Nt-IgD6tDD_PnoJ0T--xfiPrFc&m=aRQn0HhF1ltMyQGFZDiwFnEqUmjSVw7eCqnrGk8RHuk&s=GOMYRJm-ecqGd2IlcdgN0FWoryvxNJmFnGbciVKdwtg&e=>: Message disposition notifications are requested by including a Disposition-Notification-To header in the message. Further information to be used by the recipient's MUA in generating the MDN may be provided by also including Original-Recipient and/or Disposition-Notification-Options headers in the message. -> that would indicate that my implementation is incorrect. I also didn't find any reference in RFC 4130. Any objections on deleting these checks? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_phax_as2-2Dlib_issues_42-23issuecomment-2D401370660&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=jXF8HD16qCr9zl7f4Nt-IgD6tDD_PnoJ0T--xfiPrFc&m=aRQn0HhF1ltMyQGFZDiwFnEqUmjSVw7eCqnrGk8RHuk&s=dk18ELHVVkRyZcPYPVJzrrsCAUBJ_zX_FwcIqchF2Xk&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ALHxET8vmUprBpr0p2aUGUvu-5F4-5FbPWrTks5uBjkYgaJpZM4U8W2m&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=jXF8HD16qCr9zl7f4Nt-IgD6tDD_PnoJ0T--xfiPrFc&m=aRQn0HhF1ltMyQGFZDiwFnEqUmjSVw7eCqnrGk8RHuk&s=b_xu2ZSrugV-OW5qxWpdub0vdsOBEGsGR7tpwsFet1c&e=>.

[phax]

It is already deleted in master branch. Please check the Snapshot version and tell me if it works.
I'm on vacation for one week so I will not respond.

[open-gdsn]

We are currently looking into use AS2-Lib as a replacement of our (previously certified) AS2 software. What should be kept in mind regarding interoperability is that in some case, the implementations of the certified software deviates from the specs if all certifying parties agreed on that in the certification process. Iirc (did not work here when the software was certified), these Drummond certification tests and reports can be found on the internet.

[phax]

@open-gdsn I'm aware of this, that's why I changed this. I just forked the project, because I needed an AS2 solution and OpenAS2 development was stalled. I updated the software so that it works for me (in the PEPPOL context) and for the rest I'm relying on community input.
So everytime you find an incompatibility just let me know. As an individual not having the resources to perform Drummond testing :(
Btw. I did not release a new version, because @zharpaz is building a PR with large file support which I want to investigate before releasing.

[open-gdsn]

Sorry, I now see I used my 'wrong' GitHub account, my name is Ronald van Kuijk, usually using '@kukel' (nickname) as Gitbub account. I'll keep monitoring things ;-)

[phax]

I think it has been tested thoroughly and will be included in the 4.1.1 release

[kukel]

The value of the AS2MDNTo should (according to the specs) be in RFC2822 format and hence not being the AS2ID!. Although the spec also states that receiving systems should be very lenient, it is better to try to adhere to the specs.

7.3. Requesting a Signed Receipt

Message disposition notifications are requested as per RFC 3798. A
request that the receiving user agent issue a message disposition
notification is made by placing the following header into the message
to be sent:

    MDN-request-header = "Disposition-notification-to"
                        ":"  mail-address

The following example is for requesting an MDN:

    Disposition-notification-to: [email protected]

This syntax is a residue of the use of MDNs using SMTP transfer.
Because this specification is adjusting the functionality from SMTP
to HTTP while retaining as much as possible from the [4]
functionality, the mail-address MUST be present. The mail-address
field is specified as an RFC 2822 localpart@domain [addr-spec]
address. However, the address is not used to identify where to
return the MDN. Receiving applications MUST ignore the value and
MUST not complain about RFC 2822 address syntax violations.

[phax]

Next try :)