[Devel] From: header for MM4_delivery_report.REQ messages
Hi All, I am tracing an issue with regard to MM4_delivery_report.REQ messages to other MMSC's. The From: field is set to [EMAIL PROTECTED]. The other MMSC is expecting this field to be the number for the handset to which the message was sent in the first place. Like MSISDN/[EMAIL PROTECTED]. The thing is this: I am unable to find the place where this message is created in order to set that From: field. Can anyone give me a pointer in the right direction, please? ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] MM4 MMSC interworking
Hi, Related to the interworking... In mmsc/mmsglobalsender.c's method: mms_sendtoproxy there is the call to send the actual email out: x = mms_sendtoemail(from, pto, subject ? subject : settings-mms_email_subject, msgid, msg, 0, error, sendmail_cmd, settings-hostname, 0, 0,NULL,NULL,0); The question: is there any specific reason why the last parameter, append_hostname, is set to false? On 1/30/07, Paul Bagyenda [EMAIL PROTECTED] wrote: Applied to CVS. Thanks On Jan 28, 2007, at 21:06, Vincent CHAVANIS wrote: This is an update of my previous message, This should fix the duplicate entry header for the X-Mms-Message-Type. ___ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Re: [Devel] [PATCH] Usage of mms-message-too-large-txt
Hi, This patch will add the current msgid to the notify script if it is present. On 7/25/06, Deon van der Merwe [EMAIL PROTECTED] wrote: Hi Paul, On 7/25/06, Paul Bagyenda [EMAIL PROTECTED] wrote: Deon, Not a bad idea at all. Would the additional parameter to the notify- script then mean that the message-too-large field is not needed? (Or we could just leave it as empty to signal nothing-to-send). I kept all the other parameters the same: just added the message ID at the end. Busy testing it now... will send the PATCH shortly. notify_prov_server_msgid.patch Description: Binary data ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
Re: [Devel] Usage of mms-message-too-large-txt
Hi Paul, On 7/25/06, Paul Bagyenda [EMAIL PROTECTED] wrote: Deon, Not a bad idea at all. Would the additional parameter to the notify- script then mean that the message-too-large field is not needed? (Or we could just leave it as empty to signal nothing-to-send). I kept all the other parameters the same: just added the message ID at the end. Busy testing it now... will send the PATCH shortly. ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
[Devel] Usage of mms-message-too-large-txt
Hi, (not sure if this should be on the users list???) Our MMSC is configured with: notify-unprovisioned = false. We do this because we have a mms-to-local-copy-handler VASP configured that receives a copy of all MMS. This handler will also do the is destination handset MMS enabled check. If it is not enabled/capable the local-copy-handler VASP will generate a reference and send a SMS message to that subscriber. The subscriber then uses a web interface (with the above reference) to view the MMS. This works great... but the flexibility is not preset for MMS that is to big for the destiantion subscriber. There is the mms-message-too-large-txt configuration. The issue here is, that this only gives the subscriber a static link to go too. No dynamic reference for the specific MMS message. So, what I am thinking of is this: the prov-server-notify-script already passes the message_too_big status as well as the subscriber information. If we can add the msgid as another parameter to this script, then we can trigger a SMS to that subscriber with the reference (that is generated by the local-copy-vasp). sjoe... at last I get to my point! How is other people using/solving the message_to_big problem? Does the above sound like a fair/clean(ish) solution? ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
[Devel] To and CC field separation
Hi, We are seeing that some subscribers, when submitting to more than one destination at a time, will separate the fields with a space (and not a comma as they should). I will like to make a small modification to the source in order for mbuni to include the space into the parsing. Thing is that I can not find where this is done. Can anyone point me to the place, please? ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
Re: [Devel] To and CC field separation
Hi Paul, On 6/26/06, Paul Bagyenda [EMAIL PROTECTED] wrote: Deon, Short answer is that it isn't. The spec says that if there are multiple recipients, then the message will contain the To/Cc/Bcc field as many times are there are recipients. This means that the user should not, as in the case of email, put a space or whatever. So the question is: Should Mbuni worry about this? Ideas please. Had a look at our stats, and I now think the problem (USERS!) is actually very small. Out of 2150 MMS there has only been 7 like this. So, now I am thinking: maybe the sulotion is rather the validation checks of the destinations. In this case space is invalid in both numbers and email addresses. That then takes my little search to where/how/what validation does mbuni do on the destinations? ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
[Devel] mime-version header patch
Hi, Small patch to add a MIME-Version header into outbound emails. Some mailers do not display the content properly when this header is not present... mimeversion-header.patch Description: Binary data ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
Re: [Devel] user-agent and x-wap-profile integration
Hi Stipe, On 5/26/06, Stipe Tolj [EMAIL PROTECTED] wrote: Would you be open to a HTTP interface in mbuni that, if configured, will make a HTTP (get/post) to a configured URL with the user-agent as parameter. This external service will then return a profile for the device. Maybe this external can make use of the WURFL database to create a response for mbuni to use (when no wap-profile is provided). Aaaa, ok, you want a wurfl to wap-profile converter. Ok, that way we could use the wurfl database and issue wap-profile back. Would be a good idea. At least if the overleaping of the details are common, otherwise we had to much lacking information. Actually this may be layered in the WAP/HTTP proxy, rather then the MMSC layer? For the WAP1 devices: true. But for the WAP2 devices you will need something at the MMSC layer, correct? ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
[Devel] user-agent and x-wap-profile integration
Hi All, Paul pointed me to the devel list with an idea that I have... The discussion started after seeing that some Motorola phones (V3i) does not include the x-wap-profile HTTP header. From the spec's it turned out that this header is not madatory (to my great surprise!). I am playing with a idea here: does anyne else here know about the http://wurfl.sourceforge.net project? They maintain a database (of sorts) that enables you to lookup the capabilities of a device using the user-agent header. Would you be open to a HTTP interface in mbuni that, if configured, will make a HTTP (get/post) to a configured URL with the user-agent as parameter. This external service will then return a profile for the device. Maybe this external can make use of the WURFL database to create a response for mbuni to use (when no wap-profile is provided). I am able to the external service (Java based...), but not the mbuni side of things. Any comments/other ideas? ___ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
