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