Blackberry - part II
glenn.steen at gmail.com
Mon Aug 6 13:49:53 IST 2007
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
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se
More information about the MailScanner