procmail
[Top] [All Lists]

Re: Respond From:

2001-01-30 10:01:37
PNEWS is looking for a procmail solution to circumvent an ORBS block,
and I thought I had something that might help:

| That is what I want. I have been doing it with a redirection routine but
| would prefer the procmail recipe so if you don't mind, if you can find it,
| please send it to me.. Thanks............
| 
| Hank
| 
| On Tue, 30 Jan 2001, D E Hammond wrote:
| >
| > [...]
| > It got around those systems that wouldn't accept mail
| > from unresolvable domains, which was just a lot less common at that
| > time, and would work fine to get around ORBS, RBL, DUL, etc. lists.
| > Note, it doesn't rewrite the From: header because that's meaningless. It
| > works due to the envelope sender being acceptable to the destination MTA
| > because it's coming from the ISP rather than the home machine. It's
| > probably a pretty ugly kludge, and arguably this is better solved at
| > the MTA level if possible, but if it's what you're looking for I'll dig
| > it out again.

I'm not sure what you mean by redirection routine (maybe a %-hack
address?), and how it differs from my offering below. I must preface
this be saying again, IMO this is better solved at the MTA level if
possible. If you don't control the MTA at the ORBS blocked site, and
must use it to originate messages, then I guess this might help.
Finally, this is not really a circumvention of ORBS, RBL, "does not
resolve", etc., but a round-about relay kludge (send/deliver/forward).
It'll only work if you have permission to use the "intermediate" MTA
*and* it accepts incoming from the ORBS blocked site. That could change
and you'd be out of luck. So the real problem is the ORBS block and you
might want to spend some time lobbying them to fix whatever is wrong
with their configuration that got them on the list in the first place.

Final disclaimer: I've used this without mishap, but it does introduce
risk of false procmail matches doing things you don't expect. To lessen
that risk, you'll need to modify and possibly tighten recipes according
to your needs.

In an rcfile that will see the message to be forwarded (before any
other recipes that might deliver it):

:0
* ^Received:.*\.tradersdata\.com\>
* ^Message-Id:.*tradersdata\.com\>
* ^From.*deh@([a-z]+\.)?tradersdata\.com\>
* ^Subject:.*\[mailto:.*\]
{
  NEWTO=`formail -x 'Subject:' |sed 's/.*\[ *mailto: *\(.*\) *\].*/\1/'`
  SUBJ=`formail -x 'Subject:' |sed 's/ *\[mailto:.*\]//'`
#  LOG=">>>>>>>>> $RCFILE: (fixed host to $NEWTO)$NL"
  :0 fwh
  | formail -I "Subject: $SUBJ" -I "To: $NEWTO"
}
:0 A
! $NEWTO

There's no rocket science there. Pretty standard stuff.

Assuming:
    dom1.com  = ORBS blocked site
you(_at_)dom2(_dot_)com  = your address at site that accepts from dom1
user(_at_)dom3(_dot_)com = final recipient
 
I would use it from my account at dom1.com like:

mail you(_at_)dom2(_dot_)com -s "your [mailto: user(_at_)dom3(_dot_)com] 
subject here"

(Obviously, you needn't use /bin/mail. The point is the destination
address and the "tag" in the Subject:)

The message gets delivered to you(_at_)dom2(_dot_)com, where procmail does it's
thing and sends it to user(_at_)dom3(_dot_)com with the To: and Subject: headers
appropriately modified. From: is unmodified, but since the MTA at dom2
is sending to dom3, the envelope sender is ok.

Notes:
The [mailto: .*] "tag" in the Subject: can be anywhere, but I seem to
recall an extra space remaining which I might not have fixed. It's been
a long time. Whitespace after the "[" or before the "]" is ok. (I had to
make it friendly for my kids to use.)

The ([a-z]+\.)? construct will not catch any legal node name. It's only
intended to catch names I use. If you need it at all, that's one thing
that might need adjusting. The idea here is to have enough conditions to
reduce towards zero the possibility of false matches.

It seems to me that I've received mail from stupid mail clients that are
sticking html <mailto:> tags somewhere in the headers. So even though
the Subject: "tag" used here is not html, you might want to pick
something more obscure. Any of these headers can be forged, so the risk
always exists that this setup could be abused. With enough conditions
that risk can probably be made insignificant, but not eliminated.

The procmail people who are better than me can probably get NEWTO and
SUBJ using \/ intead of sed. I did what I could at the time. (Atleast
I didn't use perl ;-) You might also be told that the final "]" does not
need escaping since these are not character classes, but they're there
for my clarity.

I commented out the "LOG=" line but left it as a reminder that, if you
try something like this, do some verbose logging to debug any problems.

It's nothing special, but maybe it'll get you started.

Don Hammond


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>