fre, 11 03 2005 kl. 13:24 +0300, skrev Paul Bagyenda:
> >> -1 signals that message should be discarded (see mms_billing.h)...
> > So it does! Hmm... I still think some sort of check should be applied
> > beforehand.
> > In my little world, the provisioning stuff isn't just about capabilites
> > (MM
On Mar 11, 2005, at 12:58, Søren Hansen wrote:
fre, 11 03 2005 kl. 12:30 +0300, skrev Paul Bagyenda:
-1 signals that message should be discarded (see mms_billing.h)...
So it does! Hmm... I still think some sort of check should be applied
beforehand.
In my little world, the provisioning stuff isn't
fre, 11 03 2005 kl. 12:30 +0300, skrev Paul Bagyenda:
> -1 signals that message should be discarded (see mms_billing.h)...
So it does! Hmm... I still think some sort of check should be applied
beforehand.
In my little world, the provisioning stuff isn't just about capabilites
(MMS enabled or not),
-1 signals that message should be discarded (see mms_billing.h)...
On Mar 11, 2005, at 12:24, Søren Hansen wrote:
fre, 11 03 2005 kl. 12:21 +0300, skrev Paul Bagyenda:
The way I see it, if they can send, they've guessed the URL for our
MMSC. That doesn't necessarily mean that they should be allowed
fre, 11 03 2005 kl. 12:21 +0300, skrev Paul Bagyenda:
> > The way I see it, if they can send, they've guessed the URL for our
> > MMSC. That doesn't necessarily mean that they should be allowed to use
> > the MMSC... Or how would you block that? Can the billing module return
> > an error somehow?
>
On Mar 11, 2005, at 10:35, Søren Hansen wrote:
fre, 11 03 2005 kl. 08:05 +0300, skrev Paul Bagyenda:
It is on purpose. The thinking was: why should we check that the
sender
is provisioned? If they can send, then we know they are.
The way I see it, if they can send, they've guessed the URL for our
fre, 11 03 2005 kl. 08:05 +0300, skrev Paul Bagyenda:
> It is on purpose. The thinking was: why should we check that the sender
> is provisioned? If they can send, then we know they are.
The way I see it, if they can send, they've guessed the URL for our
MMSC. That doesn't necessarily mean that t
It is on purpose. The thinking was: why should we check that the sender
is provisioned? If they can send, then we know they are. Note that the
GW calls the prov_notify script anyway so that the provisioning server
can update its view of the senders state.
On Mar 10, 2005, at 19:53, Søren Hanse
I'm curious... Is it on purpose that there's no provisioning check of
the sender but only of the recipient?
--
SÃren Hansen <[EMAIL PROTECTED]>
smime.p7s
Description: S/MIME cryptographic signature
___
Devel mailing list
Devel@mbuni.org
http://mbuni.
