webhosting recommendations with procmail

Mon Jan 20 06:17:13 PST 2003

>Date: Mon, 20 Jan 2003 03:18:38 -0800
>From: bill at wards.net (William R Ward)

>I recommend using fetchmail on your home Linux box to pull the mail
>from your POP/IMAP account, and then run procmail locally.  That's
>what I do and it works great.

Ummm....  Back when I was a dialup customer (with a static IP
address) of an ISP that refused to deliver mail to dialup customers via
SMTP or UUCP, I used that technique (well, except I was running SunOS
4.1.1_U1 on my 3/60, vs. Linux... and it was easier for me to cobble up
a Perl script to handle the local re-delivery than to figure out how to
use procmail).

It is my perception that the cited technique can be made to work within
its inherent limitations, but I would definitely not recommend the
technique without disclosure of the limitations.

What is at issue (as far as I'm concerned) is that the technique involves
picking up the mail after "final delivery" ahs been accomplished (and
thus, after the envelope information has been discarded) and trying to
go through the process of figuring out where the message should go once
the envelope is gone.

For "normal" messages, this can work out reasonably well.  You just need
to be sure the re-delivery is only to local addresses.  (Had you been
using the technique, and had I sent this message both to you and to the
baylisa@ list, I would be rather perturbed (wearing the
postmaster at baylisa.org hat) had your system sent a copy of the message
to you, as well as re-injecting it to the baylisa at baylisa.org list.  I
expect you would be less-than-thrilled about the results of that, as
well.)

Where things really get unpleasant is where all of the following hold:

* You have multiple local recipients for messages.

* You use the same POP-box for at least 2 of the above.

* A message arrives with at least 2 of the above as recipients.

* At least one of the above recipients is specified as a Bcc:.

The salient issue is that by their nature, Bcc: recipients are *only*
specified in the envelope -- not in the message headers.  And delivery
to a POP-box (as noted above) is "final delivery" from the perspective
of the MTA, so the envelope information is discarded.

I assume(!) in the following that it is important to you that the
existence of a Bcc: recipient for a message should not be readily
apparent to other recipients of the message.

I further assume that it is important to deliver a given message (only)
to its intended recipient(s).

Given the above situation, we have incompatible requirements.  The only
ways I have found that come anywhere close to addressing the last
assumption are:

* Prior to discarding the envelope information, record the addresses (at
  least for the domain(s) served by the POP-box) in some special headers.

  Unfortunately, that risks disclosing a Bcc: recipient.

* Provide (at minimum) one copy of the message for all exposed
  recipients (for the domain served by the POP-box), and one for each Bcc:
  recipient in that domain; the latter would also have a special header
  added for the redelivery phase.

  There is something unsettling (to me) of having multiple
  instantiations of a message (i.e., same Message-Id) traversing the same
  network, but with different content (the special headers).  And changing
  the Message-ID strikes me as perversity incarnate.  Further, the
  redelivery phase would need to pay attention to the special header and
  only use that for determining the recipient(s) -- not the regular
  recipient-specifying headers (To:, Cc:, Apparently-To:, Apparently-Cc:).

Thus, from my perspective, using a single POP-box for receiving messages
for more than one recipient is a fundamentally flawed approach.

What works?  Any mechanism that preserves the envelope.  SMTP does this;
so does UUCP (for all its cruftiness).  For the case of a recipient who
has connectivity only episodically, "normal" SMTP is unlikely to be
usable; that is what ETRN is for -- as long as the connectivity is for a
static IP.  For dynamic IP, try to find an implementation of ODMR
(On-Demand Mail Relay), RFC 2645.  (Unfortunately, we (at Whistle) were
unable to get the implementation of ODMR that Jennifer Myers did
released before IBM effectively shut the operation down.  It was based
on the same queueing mechanism that Terry Lambert & I did for ETRN,
using sendmail 8.9.3 as a base, and which was the topic of the "Short
but Cool" talklet I gave on 16 Dec 1999.  That material -- including the
patches -- was released, but by that time, sendmail's queueing had
diverged from 8.9's so much that updating it to more recent sendmail
wasn't feasible, from our perspective.)

Now, all of this isn't directly helpful for the person doing the
original query.  Sorry about that.  As for me, I was lucky enough to get
a static IP assignment from Pac*Bell when I got residential DSL, and I
run my own SMTP server here at home.  I create new email aliases when
the need becomes apparent, and Things Just Work.  And if I get too much
spam from a domain or netblock, I can blacklist the domain or netblock
-- at the MTA level (where I think it should be done, if it is done).

Cheers,
david       (links to my resume at http://www.catwhisker.org/~david)
-- 
David H. Wolfskill				david at catwhisker.org
I have no confidence in results obtained through the use of Microsoft products.