Blackberry - part II

[Glenn Steen]

On 06/08/07, Alex Broens <ms-list at alexb.ch> wrote:
> Hi Glenn,
>
> On 8/6/2007 2:00 PM, Glenn Steen wrote:
> > On 06/08/07, Alex Broens <ms-list at alexb.ch> wrote:
> >> Guys
> >>
> >> Blackberry's ETP.DAT files are becomming a daily challenge:
> >>
> >> Today:
> >>
> >> ETP.DAT: SVR2 pure executable (Amdahl-UTS) not stripped - version
> >> 1197568626
> >>
> >> Last Friday
> >> ETP.DAT.old: mc68k executable (shared demand paged) not stripped
> >>
> >> a few weeks ago:
> >>
> >> ETP.DAT executable not stripped
> >>
> >>
> >> anybody know someone at Blackberry?
> >>
> >> Can't imagine a company that size can't produce a consistent file header.
> >>
> >> or any better ideas?
> >>
> >> Thanks
> >>
> >> Alex
> >>
> > As I'm sure you've done, you can look at the message ... and see that
> > it contains two parts:
> > 1) the ETP.DAT in ascii armour
> > 2) the pure binary file, containing the encrypted activation data.
> >
> > If the idiots could code their system to only work with the prior, and
> > dispensed entirely with the second... everything would be just dandy.
>
> exactly - and do would expect to get a reply from their Support? YEAH RIGHT!
>
> > As is, to be sure there is no problems activating a new handset,
> > you'll have to do something like:
> > - In /etc/MailScanner/rules/filetype.rules (referenced in the Filetype
> > Rules setting in MailScanner.conf, of course):
> > # Bloody ETP.DAT object files from blackberry...
> > From:   *.blackberry.net
> > %etc-dir%/filetype.whitelist.rules.conf
> > (beware of linewrapping....:-)
> >
> > - In /etc/MailScanner/filetype.whitelist.rules.conf .... basically
> > just say "allow" to anything. You could make that a one-liner, or copy
> > the normal filetypes rule file and change all the "deny" to "allow"
>
> Using Mailwatch, I have "content.scanning.rules"
>
> From:           127.0.0.1      no
> FromOrTo:       default        yes
>
>
> do you think it would make make more sense to add
>
> From:           *.blackberry.net      no
>
>
> to that? (and spare wathcing an extra rule file :-)

The MailWatch rules can't handle wildcards, so .. nope, that likely won't work.
One of the reasons I stick to MailScanner rules... Of course, that is
provided one don't have a need for lots and lots of rules:-).

> > There is no real way around this idiocy, since you cannot predetermine
> > exactly which hosts (IP addresses/ranges) they might be sending from,
> > nor determine exactly which file magics it can happen to match.
>
> frustrating - just hard to believe nobody else has come across this
> before :-)
>
Oh, we have... The "BB expert" from Telenor was adamant that we needed
do some "exceptions" (_very_ non-specific on the details about what to
expect...). So, since the trials went OK, I didn't do any
exceptions... until things were going production, and not working out
that well:-).

> thanks
>
> Alex
>

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se