Hi,

just few notes what 3GPP says about mentioned issues:

"When delivering a message from an MMSE to another MMSE, both the
sender and the recipient addresses shall be extended to include the
FQDN to enable transport over SMTP. This FQDN format shall be used in
the MM4 reference point. It is required that FQDN format address is
used in "MAIL FROM: " and "RCPT TO: " commands in SMTP, it is not
necessary that the originator's and recipient's addresses in [5]
"From: " or "To"–fields are re-formatted to FQDN format."

It seems that we're also missing MM4 Sender header, which is mandatory:

"STD 11 messages are required to have a "Sender:" header that
indicates the originator address (as determined by the SMTP "MAIL
From" command)."

It's studpid, but it looks like sender needs to be provided in three
different places: in mail from envelope, From and Sender headers.

On 3/27/06, Dziugas Baltrunas <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> I faced with the following issues while trying to test MM4 functionality:
>
> 1. If MMS is destined for delivery over MM4, MMS is added to the queue
> (see mmcc/mmsglobalsender.c::mms_sendtoproxy()). However, in case
> there was no client-level DLR, we never receive confirmation from MM4
> proxy, hence queue files will stay forever.
>
> I see two solutions for the problem - we should either check if there
> was client side DLR, or implement handling of MM4 .RES responses and
> put X-Mms-Ack-Request (since Rel-4) in every outgoing message which
> would say MM4 proxy to send relevant confirmation response (i.e.
> MM4_forward.RES).
>
> 2. In outgoing MM4 messages no local hostname (i.e.
> mms.mnc002.mcc246.gprs) is appended to the sender address which
> violates SMTP (sender addr. must contain FQDN). This is possible
> enable in mmcc/mmsglobalsender.c::mms_sendtoproxy() which calls
> mms_sendtoemail(), dunno why it's not yet enabled?
>
> I'm also thinking that it would be feasible to introduce new config
> parameter local-mm4-domain or similar for that purporse. We could
> reuse hostname field from mbuni group for it, but this would extend
> message IDs (since hostname is used included). The same problem
> appears in recipient domain since currently host field of mmsproxy is
> appended, but it most cases this is still feasible.
>
> --
> Dziugas
>


--
Dziugas

_______________________________________________
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org

Reply via email to