giving root simply access doing that might work, but without further thinking through it will open security issues. courier explicitly recommends bin, when you read their docs. I guess they have a reason why it shouldn't be root

Ok, root maybe only a temporary solution. But bin (in ArchLinux) doesn't work. You could test ist on command line with a root shell:
su -c "/usr/share/sqwebmail/cleancache.pl" bin
You a prompted to change your password. This is cause bin in /etc/shadow is created without the password expire fields (and not while the user has /bin/false as shell i mentioned first). It's the missing expire fields. Most other system user (daemon.mail,ftp) which are created during installation have the same behavior.

So we must either change bin user entry. Or took another user. I would prefer courier (uid 72). This user AFAIK
is created during courier installation and has correct shadow entries.

I'm not running the sqwebmail from courier, so i could'nt test it in real. But as i see the cleancache.pl
script would fail in any case, either started as bin or courier. The script does removing files in the dir /var/spool/courier/webmail-logincache. But this dir in my installation has ownership root.root and writeable
rights only for the owner. So neither bin nor courier could remove entires in this dir, even when the files or subdirs are writeable by one of them.

At my point i would say:
We must definitely change the cron job enry - under default Arch installation it couldn't work (shadow).
The only result is a failure mail to root.

I would prefer to run the perl script as courier:
su -c "/usr/share/sqwebmail/cleancache.pl" courier
This would not result in an error mail, but it still does nothing usefull (no write rights in affected dir)
So we should change ownership of /var/spool/courier/webmail-logincache to courier.courier.
If then sqwebmail works? I don't know, I'm not using it.
Some processes of courier-mta run under uid corier, some under root. When login-cache-files in above dir are
owned by root then the script maybe would fail although it started correctly.

@Tobias: so what is the decission here?

courier is a complicated beast. The documentation is both excessive and confusing. I don't use webmail either and I would like to have some input from a person that actually uses it. But that is hart to find. I think the best intermediate solution is to not install the cron job at all, people using webmail shall do that manually, they also know the correct permissions this task requires in their particular configuration.

will be fixed in testing