hi samizdat-devel,

This is a patch against 0.6.0.20070519-2.

There are several small changes from 0.1 to 0.2 of sms2samizdat.

FILES
(1) config.yaml
(2) .procmailrc
(3) frontpage_controller.rb
(4) resource_controller.rb


CHANGELOG:

A brief description of the changes:

• resource_controller  should not rely on the prefix 'sms' for

sms2email files as defined in .procmailrc - in version 0.1 it was
obligatory that filename start with the string 'sms'.

** In 0.2 this is configurable in config.yaml with e.g.
filename_prefix=sms
as the default.

• CGI.escape:

Some sms companies escape non-alphanumeric characters e.g. ",
and although they should (i presume) add this header:
 Content-Transfer-Encoding: quoted-printable
instead they only put these two headers:
 Content-type: text/plain; charset=iso-8859-2
 Content-transfer-encoding: 7BIT

** In 0.2 there's a parameter in config.yaml (by default commented
out) which if set, will call CGI.unescape( ) on both @subject and
@body of the sms/email:
 unconvert_quoted_printable: true

It does require that  Content-transfer-encoding: matches either 7BIT or
quoted-printable, which may reduce the number of cases in which it's
used unnecessarily.

However, i'm interested in what people think of the risks. Unescaping
anything is not a good idea unless you're reasonably sure that it should
be unescaped - otherwise you allow control characters etc. into your
system.

What do people think of the security aspect here?

• case insensitivity of email addresses (a mobile phone may by default

set the first letter of an address in upper case; in general case should
not matter).
** 0.2 - done

• requirement that username in From: matches /[0-9]{8}@/

** 0.2 - this requirement has been added so that it should block a fair
degree of (script kiddie type) people who might try to send ordinary
email (spam) to the address instead of sms'es. Other checks could be
possible, but in 0.1 there was no such constraint.

• protect against e.g. Subject: NaN, ensure that these are strings

** 0.2 @subject and @body are both .to_s'ed.  Without this, sending
NaN as the Subject leads to an error because it leads to a nil title,
since it's considered to be a numerical value: nil.



OTHER COMMENTS

Installing this on a production site - on an old fedora distribution -
made it impossible (or not obvious anyway) how to use .procmailrc.
Sensitivity to directory/file privileges by both the MDA for incoming
email and by the apache user made it difficult for direct communication
between the two by the creation and reading/deletion of files. So
instead i wrote a simple hardwired script for cp-ing/chmoding/chowning,
which can be run by a cron job.

Should this script be part of the samizdat distribution? IMHO mail is
a non-trivial thing (because of the well-known risks of abuse and/or
human error and/or human ignorance of email standards) and creating a
general solution which works on a wide number of systems but is also
secure is not trivial. Procmail is fairly standard, so IMHO a
.procmailrc file should be enough as part of a "standard" version
of samizdat (if the version including an sms2samizdat interface looks
anything at all like my patch :).


The code fragment in resource_controller has got longer and longer,
more like typical fortran77 ;) than ruby oo code. Any should feel
welcome to modularise/oo-ify it more.

cheers
boud



On Thu, 17 May 2007, boud wrote:

> (.) RISKS +
> **COUNTERMEASURES
> (1) email spam * use spamassassin * turn on only temporarily during rapid
> events
> ** only publish the email address widely if enough people will be online
>   to openly edit them (or possibly moderate) - the sms's are published
>   with openediting turned on.
> (2) SMS/MMSes are removed (for confidentiality) after publishing, even
>  if extraction of non-text content (photos etc) is not implemented
> ** In config.yaml turn on the parameter:   do_not_delete_old_smses  . A
>  sysadmin could then potentially publish the media items later.

...



(file #12839)