Hi,

I'm new to the list (though not really new to qmail -- used it for
approx. three years now), so please forgive my possible unawareness.

Anyway, I have the following problem and I'd like to receive pros and
cons on the solutions I'm thinking of:

At my site most users use Netscape under MS-WinNT to read and write
mail.  I also run a central mail server (qmail-1.01) where all
outgoing mail is relayed.  I now have realized that by simply entering
a different address in Netscape's
"Edit/Preferences/Mail&Groups/Identity" a user may change his
"From:" and "Return-Path:" header lines line to what he likes.

As I understand RFC 822 this is not violating the standard but in this
case a "Sender:" field should reveal the true sender's identity
(agreed?).

Netscape however does not do this.  Inserting a
"user_pref("mail.suppress_sender_header", false)" in Netscape's
prefs.js seems to have no effect under WinNT (at least for the version
I've tried).

So I'm thinking of letting qmail at our mail server correct for this
situation.

I doubt that the easiest remedy, to just bounce those messages (with
the wildcard patch and badmailfrom or the equiv. this patch uses),
will be acceptable to (some of) my users, so the idea is to let the
"Sender:"-field be added somewhere in the qmail-smtpd->qmail-queue
chain.

Now the "true" sender name will be ${TCPREMOTEINFO}@${TCPREMOTEHOST}
environment variable which is available to qmail-smtpd and also
(thanks to "execv") to qmail-queue.  This requires an identd to run on
the NT box, of course.

So far, so good.  The point where I'm undecided is the place where in
the qmail-smtpd->qmail-queue chain to add the header rewriting code.

I could do it either as a wrapper for qmail-smtpd or qmail-queue
(e.g. using Bruce Guenter's QMAILQUEUE-patch) the or by patching
either programs.

I'd prefer of course the wrapper solution as upgrading would be easier
(even though parsing the header lines would be somewhat tedious).
However, I'd like to bounce the mail if the identd-server is not
running on the other side (and hence $TCPREMOTEINFO will be empty).
This however seems hard to do with a wrapper.  As my understanding
goes I would have been forced to bypass qmail-smtpd in this case and
write the bounce mail in the wrapper.

Patching qmail-smtpd would be better from this point of view.

Another solution could be to introduce a new environment variable
(QMAILSMTPBOUNCE) which if set forces (a minimally patched) qmail-smtpd
to bounce the message and e.g. write this variable's contents as
explanation to the user.

Any comments?
Thank you for listening.

Best regards, 

Dirk


Reply via email to