[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

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

[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

[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

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

[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

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

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

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,

[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].