[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: From Corel on the EULA

In debian.devel.legal, you wrote:
>> --=20
>> The address in the headers is not the poster's real email address.  Do no=
>> t send
>> private mail to the poster using your mailer's "reply" feature.  CC's of =
>> mail=20
>> to mailing lists are OK.  Problem reports to "postmaster@umail.corel.com"=
>> . =20
>> The poster's email address is "erichf@corel.ca".
>Why are you using a fake email address in your headers?

I wrote the gateway software in question, and that disclaimer.
I'd welcome suggestions about better ways to express the situation,
which I'll describe in some detail below.

Erich's answer was...interesting...but as usual, not entirely complete
or accurate.  Ahem.  I don't recall writing any thread reorganization
software, for one thing.  It's amazing how only a dozen lines of code
with the simplest design I can think of is nearly impossible for people
to understand...

Corel has approximately 400 mailing lists subscribed to an internal
news/mail gateway that I wrote (the NNTP server is 'sn' by Harold Sn,
somewhere in Singapore IIRC, the SMTP server is 'exim', and the stuff
that goes between the two and makes it into a gateway is mine).  The
header rewrite solves a number of problems:

1.  Some of those mailing lists are technically incapable
of transmitting email to email addresses with certain encoding
characters (e.g. foozbibl=erichf=corel.ca@umail.corel.com).  One
degenerate case is unable to cope with non-alphanumerics at all
(not even ".").

2.  Some mailing lists restrict posting privileges to email addresses
that are subscribed or registered with the mailing list only.  Most
have restrictions about the sender's domain name--and those that don't
have subscribers that do.

3.  Some mailing lists generate traffic indistinguishable from "normal"
email or other mailing lists.  Mail that bounces upon delivery from 
certain broken mailing lists (ones that don't rewrite the sender header)
also generates sorting problems.

A solution to problem 1 and 3 is to subscribe each mailing list carried
on the gateway to a unique email address.  That solves the mail sorting
issue because the mail can be sorted by envelope recipient address
(as God herself intended it should be done, IMNSHO) with zero ambiguity.

A solution to problem 2 is to simply masquerade every user of the
gateway as the email address on the gateway that is subscribed to the
mailing list, by rewriting the "From" address on all outgoing mail.

The sum total of the mailing list/news gateway is three perl scripts:
one to sort incoming mail according to envelope recipient address, 
one to rewrite mail headers on outgoing mail according to newsgroup
name, and the third to set up the database of newsgroups and send
subscribe messages.

This effectively makes all posters through the gateway appear to be a
single user with a single email address that has a short user ID field
with no special characters and which is subscribed to the mailing list,
which is just about the only situation that the lowest common denominator
mailing list can cope with.

One problem with these solutions is that they create a side-effect:
the normal "reply" function of most mailers then sends off-list reply
mail to the masqueraded "From" address instead of the poster's real
email address.  For me at umail.furryterror.org, this isn't a problem...
any.random.string@umail.furryterror.org _is_ me (well, me and my SO),
but at Corel it's a bit more complicated.

You can actually reply to the email address in the "From" line, and Erich
will be able read it (understanding it, or taking reasonable action based
upon it, are totally different matters of course--I only do transport
and delivery ;-).  The difference between 'erichf@corel.com' and the
"fake" address is that mail sent to the "fake" address is distributed
to anyone in the company who wants to read it.

Corel was starting to get questions about sales and co-marketing deals
on the gateway meant for Erich and everyone in the company (including
myself, who has nothing to do with Corel Linux) were able to read them.
This is where the disclaimer came in.

I don't speak for Corel. zygob@corel.ca at work, zblaxell@furryterror.org
at play.  GPG-encrypted email preferred at zblaxell@feedme.hungrycats.org
GPG fingerprint:  2B32 546D 21A5 0DB2 20C8  AF10 1D4A 610E 6972 2DEE
GPG public key:  http://www.hungrycats.org/~zblaxell/gpg-public.txt

Attachment: pgpVjC4Oi0NZ3.pgp
Description: PGP signature

Reply to: