Another cheap chinese Android phone adventure

Well, because I'm an idiot I've gone for another Chinese imported phone!
The reason? My last chinese phone has developed an annoying fault with it's USB charge port, seems the connector is damaged and only occasionally takes power and charges the phone, so it's no longer reliable.
So I decided to try another one.

I ordered this phone from China (via wish) as specs were high and it was worth a bit of a gamble. Stated specs/product:

Quote:

CPU: MTK6595 Octa Core
System: Android 9.1
ROM: 128GB
RAM: 6GB
Screen Type: 6.3 inch full
Touch Screen: Support Capacitive
Resolution:Front 800MA makes you more beautiful！
Network: 4G
Network mode: GSM/WCDMA
Network: Dual SIM Cards Support T Card
Camera typeual Rear Camera One Front Camera
Camera Pixel:
Front Camera：800 MP
Rear Camera: 16.0 MP
Software: Play Store, Air, Distance, Gesture, SmartWake,

And lots more impressive information.
The bits that made me look interested was 6Gb RAM and Android 9.1. Ignoring the usual Chinese rubbish about how good it was, and how it made me more beautiful I thought I'd try it. After shipping it was around 80UKP.




Arrival was within the stated time, but after starting to install apps and get used to the phone I found a few oddities. A few apps wouldn't install, saying not compatible with the phone, and it lagged at times quite badly for larger apps (facebook, whatsapp, etc).

I then thought I'd delve in deeper and see more info, checking the about page (and enabling developer mode) I saw the stats and a few bits didn't add up.
Android patch level seemed old for such a newly built kernel. Kernel was supposedly built April 2019.
So I fired up ADB and wow, I found some interesting facts!




The product listed itself as the P35_Pro product with an ID of LMY47I. The hardware is mt6580 which is an older Mediatek chipset.

Quote:

[ro.product.brand]: [Welcome]
[ro.product.cpu.abi2]: [armeabi]
[ro.product.cpu.abi]: [armeabi-v7a]
[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: []
[ro.product.cpu.abilist]: [armeabi-v7a,armeabi]
[ro.product.device]: [P35_Pro]
[ro.product.locale.language]: [en]
[ro.product.locale.region]: [US]
[ro.product.manufacturer]: [alps]
[ro.product.model]: [P35 Pro]
[ro.product.name]: [P35_Pro]

And then the magic part, the android release, SDK and security_patch level:

Quote:

[ro.build.host]: [mht-15]
[ro.build.id]: [LMY47I]
[ro.build.product]: [P35_Pro]
[ro.build.tags]: [release-keys]
[ro.build.type]: [user]
[ro.build.user]: [android]
[ro.build.version.all_codenames]: [REL]
[ro.build.version.base_os]: []
[ro.build.version.codename]: [REL]
[ro.build.version.incremental]: [1555497787]
[ro.build.version.release]: [5.1]
[ro.build.version.sdk]: [22]
[ro.build.version.security_patch]: [2016-06-01]

So it's actually running Android 5.1 Lollipop with an SDK of 22, security patch from 2016! So nowhere near Android 9.1. So my guess is the about app in the phone is hard-coded to hide what's truly running.
Memory is also different to stated:

Quote:

Processor : ARMv7 Processor rev 3 (v7l)
processor : 0
BogoMIPS : 15.70
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 3

Processor : ARMv7 Processor rev 3 (v7l)
processor : 1
BogoMIPS : 15.70
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 3

Hardware : MT6580WP
Revision : 0000
Serial : 0000000000000000
shell@P35_Pro:/ $ cat /proc/meminfo
MemTotal: 2022700 kB
MemFree: 106920 kB
Buffers: 6436 kB
Cached: 599428 kB
SwapCached: 268 kB
Active: 912156 kB
Inactive: 588852 kB
Active(anon): 620728 kB
Inactive(anon): 276328 kB
Active(file): 291428 kB
Inactive(file): 312524 kB
Unevictable: 1424 kB
Mlocked: 4 kB
HighTotal: 1555456 kB
HighFree: 27680 kB
LowTotal: 467244 kB
LowFree: 79240 kB
SwapTotal: 163836 kB
SwapFree: 16 kB
Dirty: 40 kB
Writeback: 0 kB
AnonPages: 896404 kB
Mapped: 310784 kB
Shmem: 484 kB
Slab: 48328 kB
SReclaimable: 20672 kB
SUnreclaim: 27656 kB
KernelStack: 16976 kB
PageTables: 28424 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1175184 kB
Committed_AS: 31332204 kB
VmallocTotal: 499712 kB
VmallocUsed: 102800 kB
VmallocChunk: 131012 kB

So only 2Gb of memory.



Now, I don't need a lecture about buying from Chinese sites/etc, I expected there to be problems, etc, but maybe not quite this level! I'm going to complain and see if I get anything, I doubt it. Otherwise it's a functioning phone, seems OK. I'll be watching it closely to see what else unusual I find with it.

(All images at: https://imgur.com/a/u1OZo4A)

gmail/google mail sending from Postfix

Here's a nasty little change that google/gmail sneaked in over the past couple of months in 2019, adding further authentication/authorisation checks for sending emails to anyone on a google hosted domain/gmail account.

The problem? Mails sent to google hosted/gmail accounts get bounced with a not very clear message:

relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c09::1b]:25, delay=0.62, delays=0.08/0/0.26/0.28, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[2a00:1450:400c:c09::1b] said: 550-5.7.1 This message does not have authentication information or fails to pass 550-5.7.1 authentication checks. To best protect our users from spam, the 550-5.7.1 message has been blocked. Please visit 550-5.7.1   https://support.google.com/mail/answer/81126#authentication for more 550 5.7.1 information.

So like a good user, you go to the url and lookup the address, which you're told all about bulk messages, mailing list best practices and pretty much it. It doesn't actually address the reasons specifically behind this error.
I suspect this is because it's a generic failure message that google are using, generally rejecting mail that they don't want to accept.

Now in this case, it's from an SMTP mail gateway/relay that several hundred people are behind it, this is a mail relay for an ISP connection, so the users behind it are of varying tech background, but are all on a known connection and various protection mechanisms are already in place to avoid spam and junk going over that connection. Therefore we believe the connection isn't generally junk/blacklisted. SORBS (urgh) and all the other mail checks show the server as clean and not listed, so WHY has google blocked/rejected mail?
Also to add to it. It's not all emails, just some get bounced like this. Send to the same recipient and sometimes it'll get through, sometimes it won't. No real recognition of why, different google gateways/IPs do the same. IPv4 or IPv6 just the same, so no real connection between which ones fail and which ones succeed.

The first thing to add was to create SPF records for the top-level mail relay server, and then get clients sending through it to add an include on their DNS records. This didn't appear to make any difference. Again some rejected some succeeded.
The only last option was to implement DKIM to the relay. This is kinda tricky as DKIM wasn't exactly designed for this scenario. Multiple sending domains, IPs, etc, all going via one mail relay. So the mail relay would need to add the DKIM signature based on it's own signing regardless of who sent it (Since we authenticate/verify senders via the server, we KNOW when an email is accepted to be relayed that it's legit).

To implement, first we have the current setup:
Postfix accepting on 25 for relaying mail out.
Multiple domains/IPs sending via Postfix, we don't KNOW all domains/IPs sending through us.
Debian/Ubuntu standard Postfix install/setup for mail relaying.


The first parts are standard installation steps for DKIM:
apt-get install opendkim opendkim-tools
Then you need to configure the base opendkim package:
/etc/opendkim.conf
/etc/default/opendkim

Configuration here is pretty basic, the key parts you need though are:
/etc/opendkim.conf:
Syslog                  yes
SyslogSuccess yes

LogWhy yes

Canonicalization        relaxed/simple

Mode                    s

SubDomains              yes

KeyTable        /etc/postfix/dkim_key_table

SigningTable    refile:/etc/postfix/dkim_signing_table

ExternalIgnoreList      refile:/etc/postfix/opendkim-TrustedHosts

InternalHosts   refile:/etc/postfix/opendkim-TrustedHosts

So the above sets Syslog to log success and failure reasons. We set Canonicalization to relaxed/Simple as this relaxes the signing. Mode is set to sign and not verify (We only relay outbound via this server, we don't want to check mail coming in for DKIM signatures/validation).

Then the Keytable, SigningTable, ExternalIgnoreList and InternalHosts contain the main parts to allow us to sign any mails going through.

/etc/postfix/dkim_key_table:

mail  serverrelay.mydomain.com:mail:/etc/postfix/dkim.key

Set "mail" as our signing name (keep it consistent throughout), define our servers name "serverrelay.mydomain.com" is our FQDN for our sending server. Again set our signing name and the path to our key.

(We'll generate the dkim.key file in a moment)

/etc/postfix/dkim_signing_table:

*  mail

This sets the domain/entries we want to sign, so the * means anything/all and again "mail" is our signing name setup above.

/etc/postfix/opendkim-TrustedHosts:

127.0.0.1

0.0.0.0/0

This defines what IPs are "trusted", i.e. allowed to be DKIM signed by us. In our instance we've set this to localhost and then to anything. This means that anything postfix is allowed to relay is allowed to be DKIM signed too. (Here we are assuming trust from postfix not being an open relay)

/etc/postfix/opendkim-TrustedHosts:

^^^ points to the above file as it's the same thing.

/etc/default/opendkim

Edit this and set the SOCKET to listen locally, by setting:

SOCKET="inet:8891@localhost"

As we want to use this to simplify our link into postfix (Since postfix is generally chroot'ed and using unix sockets/paths can get complex), easiest to use a tcp listen port.

Now we generate our signature:

cd /etc/postfix;opendkim-genkey -t -s mail -d serverrelay.mydomain.com

As above, "mail" is our signing name and our fqdn is at the end. This generates the files mail.private and mail.txt in the "current" directory, hence changing to /etc/postfix first. Then copy the files to be the ones you defined above in the config:

cp /etc/postfix/mail.private /etc/postfix/dkim.key

The /etc/postfix/mail.txt contains the DNS record you'll need to add to your DNS. So ours generated:

mail._domainkey IN TXT "v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKjCZppULxQyiblah+blah+blah" ; ----- DKIM key mail for serverrelay.mydomain.com

So create that in your DNS. I created it under the subdomain "serverrelay.mydomain.com" and the TLD "mydomain.com" to be sure.

Restart opendkim (service opendkim restart) and check it's running and listening on port 8891.

Then we can integrate into postfix:

milter_protocol = 2

milter_default_action = accept

milter_connect_macros = j {daemon_name} v {if_name} _

smtpd_milters = inet:127.0.0.1:8891

non_smtpd_milters = $smtpd_milters

Add this to your /etc/postfix/main.cf to incorporate the milter/opendkim into your install. If you already have other milters then append the inet line onto the end.

Restart postfix and then watch the mail logs for the opendkim signing taking place.

You should see:

May 17 10:48:59 serverrelay opendkim[24500]: 2A9823C156C: DKIM-Signature header added (s=mail, d=serverrelay.mydomain.com)

For each email sent through the server.

Good luck and hopefully that has helped you out! This was a combination of information I gleaned from several sources as none seemed to join all the parts together for this particular mail relaying scenario.