How do I change the sender address depending on the recipient?

In article <48b5ea0f$0$199$e4fe514c@news.xs4all.nl> Kees Theunissen
<theuniss@rijnh.nl> writes:
>Tuc wrote:
>> On Aug 22, 5:44 am, FC <f...@yahoo.fr> wrote:
>>> Hi,
>>>
>>>> Has anyone gotten "How do I change the sender address depending on the
>>>> recipient?"
>>> Do you really need to do this with sendmail ? I think procmail could do
>>> this nicely...
>>>
>>> FC.
>>
>> I'd be interested to hear how to use procmail to send mail outbound.
>
>Include a line reading
> MAILER(`procmail')dnl
>in your .mc file.
>Select this mailer for specific recipients like you selected a modified
>SMTP mailer as described by Claus Assmann in
> http://www.sendmail.org/~ca/email/lfaq.html
>
>Don't confuse MAILER(`procmail') with procmail used as the local
>delivery agent through FEATURE(`local procmail'). On Linux systems
>FEATURE(`local procmail') is often included -in a way not directly
>visible- through the use of OSTYPE(`linux').

It's a nice idea in theory (the procmailrc would have access to sender
and all recipient addresses as $1, $2, etc) - the problem is that
procmail really can't send mail, so it has to pass the message back to
sendmail for that, and then unless the recpient(s) is/are different, it
will be passed right back to MAILER(`procmail')... So you have to play
some tricks like adding and removing a .PROCMAIL pseudo-domain at
exactly the right places, and then you find that this breaks things left
and right, and...

It's still great if you want to do some very specific processing of mail
that is really to be delivered locally (or to some other program), but
not have "standard local delivery". I did try to come up with a scheme
to use it for general filtering/forwarding way back, but there was
always some little bug left no matter how much I tweaked it - and now
that the milter functionality is available, I think it just isn't worth
the trouble to try to get a procmail scheme working right.

--Per Hedeland
per@hedeland.org

Tuc wrote:
>
> Ok, a bit of an update.....
>
> I did find that $&f is valid, sorry about that.
>
> If I replace the "mailid" rule with
>
> R$* $:$(variout $&u $: $1 $)
>
> in Sfinal=4, I get a weird thing happening.
>
> 1) Doesn't change the "Return-Path" (When viewed in Yahoo!), which my
> old mailid did.

According to the Sendmail "INSTALLATION AND OPERATION GUIDE"
(on my Slackware 12.1 system: /usr/doc/sendmail-8.14.2/op/op.txt
after invoking "make op.txt" in the /usr/doc/sendmail-8.14.2/op
directory) the $u macro is assigned a value while processing the
mailer specific recipient rewriting:

When sending, the $h, $u, and $z macros get set
to the host, user, and home directory (if local) of
the recipient. The first two are set from the $@ and
$: part of the rewriting rules, respectively.

This makes the values assigned to the macro's dependent to oder
in which the header/envelope sender/recipient addresses are
processed.

It looks like the envelope sender (your Return-Path) is processed
before the recipient rewriting logic assigns a value to $u.
In case of a multiple recipient message I guess you might see the
address of the previous recipient still assigned to $u while
processing the envelope sender for the next recipient.


> 2) Changes the sender to what I want (YEAH!)
> 3) Changes the recipient to what it changes the sender to (BOO!)

Yes. Ruleset final=4 is invoked after both the (mailer specific)
sender and recipient rewriting. You could test the value of
${addr_type} to distinguish between sender and recipient:

${addr_type}
The type of the address which is currently being
rewritten. This macro contains up to three char-
acters, the first is either `e' or `h' for enve-
lope/header address, the second is a space, and
the third is either `s' or `r' for sender/recipi-
ent address.

>
> I figured that #3 was a side effect of putting it in Sfinal=4 when it
> belongs in SParseLocal=98
> I think. Why #1 isn't changing, THAT I'm totally puzzled about....
>
> If I do put it in SParseLocal=98, nothing happens ANYWHERE. :-/

Rule set ParseLocal=98 is only (indirectly) called from the rule set
parse=0 to select a mailer for a specific recipient. The mailer
selection doesn't have any effect (apart from the mailer specific
rewriting rules) on the sender and recipient addresses as seen by the
receiving mail server.

I think that you would save yourself a lot of trouble by implementing
your desired functionality through a milter (MimeDefang would be my
first choise; a very good -universal and easy to implement- framework
IMHO) or through the procmail mailer (see my other relpy in this thead).


Regards,

Kees.

--
Kees Theunissen.

On Aug 27, 8:17 pm, p...@hedeland.org (Per Hedeland) wrote:
>
> >If I replace the "mailid" rule with
>
> >R$* $:$(variout $&u $: $1 $)
>
> >in Sfinal=4, I get a weird thing happening.
>
> >1) Doesn't change the "Return-Path" (When viewed in Yahoo!), which my
> >old mailid did.
>
> Somewhat strange, all addresses should be passed through S4 at the end,
> but there's probably some explanation... A good test to see exactly how
> the different envelope/header sender/recipient addresses are run through
> the different rulesets is to run something like (as root)
>
> (echo To: <header-recipient>; echo From: <header-sender>) |
> sendmail -Am -odi -d21.<x> -f <envelope-sender> <envelope-recipient>
>
> Replace <x> with a number depending on how much detail you want,
> e.g. start at 2 and go up, and replace the <addresses> with real ones -
> but for maximum illumination, use different ones for header vs envelope.
> (It's the envelope sender that eventually ends up in Return-Path.)
>

Thanks. I think there needs to be more to it somewhere, since
when I ran it I was seeing :

-----rule matches: $: $( variout $&u $: $1 $)
rewrite: RHS $&{u} => "(NULL)"

so I'm not feeding it enough information somewhere to make it
happy it seems. :-/

>
> >2) Changes the sender to what I want (YEAH!)
> >3) Changes the recipient to what it changes the sender to (BOO!)
>
> That is to be expected.
>

Yup, that it is.. More on this later though.

>
> >I figured that #3 was a side effect of putting it in Sfinal=4 when it
> >belongs in SParseLocal=98
>
> No it doesn't - S0 (ParseLocal is a "subruleset" of S0) is for the
> routing decisions, what you do there will affect the envelope recipient
> address - but this doesn't normally appear in the final message (except
> possibly as a "for" in a Recieved header). (The envelope sender address
> is actually run through S0 too, but the result doesn't affect the final
> message except if you use some "unusual" mailer flags...)
>
I'm getting a really weird thing happening and am now even more
puzzled than ever. Infact, the some of the facts now make me think my
ORIGINAL
rules are not operating on all cylinders properly.

Clean the slate. No special rules, no special configs, etc. .
It'd be a bit big to include
my full .mc, so it should be noted its fairly generic, EXCEPT for :

MASQUERADE_AS(`example.com`)
LOCAL_CONFIG
# Outbound mail id
Kmailid hash /etc/mail/mailid

I then put at the VERY bottom of Sfinal=4 :

R$-@example.com $:$(mailid $1 $: $1@example.com $)
R$-@laptop.example.com $:$(mailid $1 $: $1@laptop.example.com $)

My /etc/mail/mailid looks like :

foo fromfoo@example.com
bar frombad@corp.example.com
foobar offical@corp.example.com

My machine name is "laptop.example.com".

So I'm user foobar (And there are list readers here that would
totally agree with that. ).
When I mail out, it looks like it came from
official@corp.example.com . When I deal with alot
of companies, I like to "personalize" my address. So I'll go in and
change it to :

foobar hp@corp.example.com

when I deal with HP.

I use a mailer that appends to EVERY email I send :

Return-Receipt-To: <official@corp.example.com>
X-Confirm-Reading-To: <official@corp.example.com>
Disposition-Notification-To: <official@corp.example.com>

If I send a mail from a user NOT in the Kmailid file, heres what
happens ...

1) EHLO laptop.example.com (Expected)
2) MAIL From:<user@laptop.example.com> (Expected)
3) From: USER <user@example.com> (Expected due to the MASQUERADE)
4) Return/Confirm/Disp untouched (Expected)

If I send a mail from a user IN the Kmailid file, heres what
happens...

1) EHLO laptop.example.com (Expected)
2) MAIL From:<official@corp.example.com> (Expected, what I wanted
from Kmailid)
3) From: Foobar <official@corp.example.com> (Expected, again
Kmailid)
4) Return/Confirm/Disp untouched (PREVIOUSLY expected, but not
sure due to what
follows)

So, now I change the Kmailid to Kvariout, and change the file
from /etc/mail/mailid
to /etc/mail/variout . I load /etc/mail/variout with :

myhpcontact@hp.example.com
hp@corp.example.com

I then change the 2 lines in the bottom of Sfinal=4 from :

R$-@example.com $:$(mailid $1 $: $1@example.com $)
R$-@laptop.example.com $:$(mailid $1 $: $1@laptop.example.com $)

to

R$-@example.com $:$(variout $&u $: $1@example.com $)
R$-@laptop.example.com $:$(variout $&u $: $1@laptop.example.com
$)


SO, effectively, I've changed it that instead of looking up from
mailid using $1,
it looks up from variout using $&u. In my eyes, not a major change.
I've changed the
file that it pointed to, and the key used. Harmless, or so it should
be. Running it, I get:

1) EHLO laptop.example.com (Expected)
2) MAIL From:<foobar@laptop.example.com> (*UNEXPECTED* What went
wrong?)
3) From: Foobar <official@corp.example.com> (Correct)
4) Return/Confirm/Disp .. Return-Receipt-To and X-Confirm-
Reading-To are untouched,
BUT Disposition-Notification-To is now set to
official@corp.example.com (HUH?!?!?!?
If all 3 went in the same, WHY do 2 escape getting changed and one
does. And if the rules
are changing it HERE, why then did they never change them before)

So I'm a bit confused here. I would have expected that changing
the name of the file and the key would have had the same effect as
before, but now it isn't changing the SMTP "MAIL From:", and I don't
know if the old rule WASN'T changing the Return/Confirm/Disp when it
should have, or what allowed the new change to have it happen.

To me, this is so wonky, I have to be tickling something in the
system. Is $&u weird in how
it works that its getting reset/wiped part way through the processing?
Should I just give up (As you mentioned I should before) or should I
start to persue this with the sendmail people for a "Is this sane?"
issue?
>
> You may want to try the mailer S= rulesets (envelope/header) as you are
> playing with a special mailer anyway. But in any case you will have the
> problem that if there are multiple recipients, $u (a.k.a. $&u) will not
> be set. Or at least that's the case for the "normal" rulesets - I think
> it's the same in the mailer-specific ones. And of course if you have
> multiple recipients and haven't split them out to separate mailers, you
> may have conflicting requirements for the sender...
>
> --Per Hedeland
> p...@hedeland.org

I stopped with the special mailer a while back. I decided that I
needed to do this for every email anyway, and with the maps if I don't
get a hit I just reconstitute the address anyway.

Yea, I know about the $&u + multiple issue. I realize this isn't
a "covers everything" issue. I so RARELY RARELY RARELY ever email 2
people for anything that I'm willing to live with
unexpected results if I do.

Per, I really appreciate the help, sorry if I'm taxing you on it
any. If my test of $&u had failed completely, I was ready to walk
away. But now with this wild results, I'm more interested in
understanding why....

Thanks, Tuc

On Aug 27, 9:17 pm, Kees Theunissen <theun...@rijnh.nl> wrote:
>
> > 2) Changes the sender to what I want (YEAH!)
> > 3) Changes the recipient to what it changes the sender to (BOO!)
>
> Yes. Ruleset final=4 is invoked after both the (mailer specific)
> sender and recipient rewriting. You could test the value of
> ${addr_type} to distinguish between sender and recipient:
>
> ${addr_type}
> The type of the address which is currently being
> rewritten. This macro contains up to three char-
> acters, the first is either `e' or `h' for enve-
> lope/header address, the second is a space, and
> the third is either `s' or `r' for sender/recipi-
> ent address.
>
I missed reading this. (I found I was reading an OLD OLD copy of
the
op-5 file, and just skimmed the new one from the lastest version to
see
it had ALOT of new stuff I needed to look into. Thanks.
>
> I think that you would save yourself a lot of trouble by implementing
> your desired functionality through a milter (MimeDefang would be my
> first choise; a very good -universal and easy to implement- framework
> IMHO) or through the procmail mailer (see my other relpy in this thead).
>

I do appreciate your input too Kees. I had pretty much resolved I
was
going to head to MimeDefang (I was there once ages ago for something
I
can't even remember, and it never happened) when the $&u was a total
flop. Problem is $&u PARTLY worked and now I wonder WTF happened.
But I'm still starting to read the MD info.

Thanks, Tuc

Tuc <tuctboh@gmail.com> writes in comp.mail.sendmail:

> 4) Return/Confirm/Disp .. Return-Receipt-To and X-Confirm-
> Reading-To are untouched,
> BUT Disposition-Notification-To is now set to
> official@corp.example.com (HUH?!?!?!?
> If all 3 went in the same, WHY do 2 escape getting changed and one
> does. And if the rules
> are changing it HERE, why then did they never change them before)

See
sendmail/conf.c

/ Kari Hurtta

On Aug 29, 12:02 am, Kari Hurtta <hurtta
+comp.mail.sendm...@siilo.fmi.fi> wrote:
> Tuc <tuct...@gmail.com> writes in comp.mail.sendmail:
>
> > 4) Return/Confirm/Disp .. Return-Receipt-To and X-Confirm-
> > Reading-To are untouched,
> > BUT Disposition-Notification-To is now set to
> > offic...@corp.example.com (HUH?!?!?!?
> > If all 3 went in the same, WHY do 2 escape getting changed and one
> > does. And if the rules
> > are changing it HERE, why then did they never change them before)
>
> See
> sendmail/conf.c
>
> / Kari Hurtta

I'm not really sure what you want me to look at, sorry. I see
that there is a structure called "HdrInfo", and it includes "return-
receipt-to" (H_RECEIPTTO) and "disposition-notification-to" (H_FROM),
but not "X-Confirm-Reading-To" (Upper or lower). If I was to theorize
what that is for, its items that could be acted upon by the rules to
be changed.

If my guessing is correct about what I should be looking at, it
still gets back to the following issues :

1) Previously, with Kmailid and $1 as the key, NONE of the 3 I added
to the header were changed.
2) Changing to Kvariout and $&u as the key, only the Disposition-
Notification-To changed.

If it only works on "H_FROM" items, then why did it never
originally change the
Disposition-Notification-To ever before? The ONLY change between the
two sets of rules is the K name, and the key. If the key exists, one
would expect the behaviour to be completely the same. I akin this to
loading 12 rows in 2 different database tables, doing a "SELECT
COUNT(COL1) from TABLE1" and getting 12, and "SELECT COUNT(COL3) from
TABLE2" and getting 9. (And now because of the Disposition-
Notitification-To issue from the $&u, I'm thinking that the first
table was returning a count of 11.

And if this isn't the line of thought I should have from the
reference, could you please go into more details?

Thanks, Tuc

On Aug 27, 9:17 pm, Kees Theunissen <theun...@rijnh.nl> wrote:
>
> I think that you would save yourself a lot of trouble by implementing
> your desired functionality through a milter (MimeDefang would be my
> first choise; a very good -universal and easy to implement- framework
> IMHO) or through the procmail mailer (see my other relpy in this thead).
>
I'm still wanting to find out why sendmail goes all bonkers if I
change the map name and the key, but in the mean time I've created the
functionality in MimeDefang... I added :

sub filter_initialize {
require DB_File;
use Fcntl;

tie %mailid, "DB_File", "/etc/mail/mailid.db", O_RDONLY;
tie %variout, "DB_File", "/etc/mail/variout.db", O_RDONLY;
}

and at the bottom of filter_end I added :

if ($Sender =~ /^<(.*)\@laptop.example.com>$/) {

$GUser = $1;

$head = $entity->head;
$From = $head->get('From',0); chomp ($From);
$RRT = $head->get('Return-Receipt-To',0);
if ($RRT) {
$XCRT = $head->get('X-Confirm-Reading-To',0);
$DNT = $head->get('Disposition-Notification-To',0);
}

$LookupRecipient = @Recipients[0]; #Per will hate this, shame
on me
$LookupRecipient =~ tr/<>//d;

$varilookup = $variout{$LookupRecipient};

if ($varilookup) {
$changeto = $varilookup;
} else {
$mailidlookup = $mailid{$GUser};

if ($mailidlookup) {
$changeto = $mailidlookup;
} else {
undef $changeto;
}
}

if ($changeto) {
$From =~ s/<.*\@laptop.example.com>/<$changeto>/;
action_change_header('From',$From);

if ($RRT) {
action_change_header('Return-Receipt-To','<'.$changeto.'>');
action_change_header('X-Confirm-Reading-To','<'.
$changeto.'>');
action_change_header('Disposition-Notification-To','<'.
$changeto.'>');
}

change_sender($changeto);
}
}


But, of course, running into 2 problems.....

1) Permissions on /etc/mail/*.db are 640, with o/g of root/wheel. For
now I changed my Makefile to make them 644. (Its my laptop, not too
worried about other people peeking)

2) When I make a change to the map and remake it... MIMEDefang doesn't
pick it up until I restart it. OUCH! I ran into this same issue with
Squid too. Maybe time to really delve into it.

Still hoping to hear back from Kari or someone else explaining
why things went all
weird just by changing the map name and key.

Thanks, Tuc

Tuc wrote:

> 2) When I make a change to the map and remake it... MIMEDefang doesn't
> pick it up until I restart it. OUCH! I ran into this same issue with
> Squid too. Maybe time to really delve into it.

That's standard UNIX behavior. When you erase or replace a file that is
in use by one or more programs, then the original file will be kept on
disk -although without directory entries referencing the file- until
the last program closes the file. Or in other words: when a program
opens a file it can trust that it is using the same file on successive
reads or writes from/to the file.
Of course it's possible to overwrite the data of an existing file
-regardless of being in use by an other program- without erasing
the file if you really want. Be prepared to properly handle data
inconsistencies if you do so.

Instead of restarting MimeDefang (and Sendmail) after a map update
it's sufficient to run:
md-mx-ctrl reread


From the md-mx-ctrl(8) manpage:

reread Forces mimedefang-multiplexor to kill all idle slaves,
and terminate and restart busy slaves when they become
idle. This forces a reread of filter rules.


Regards,

Kees.

--
Kees Theunissen.

On Aug 31, 6:16 pm, Kees Theunissen <theun...@rijnh.nl> wrote:
> Tuc wrote:
> > 2) When I make a change to the map and remake it... MIMEDefang doesn't
> > pick it up until I restart it. OUCH! I ran into this same issue with
> > Squid too. Maybe time to really delve into it.
>
> That's standard UNIX behavior. When you erase or replace a file that is
> in use by one or more programs, then the original file will be kept on
> disk -although without directory entries referencing the file- until
> the last program closes the file. Or in other words: when a program
> opens a file it can trust that it is using the same file on successive
> reads or writes from/to the file.
> Of course it's possible to overwrite the data of an existing file
> -regardless of being in use by an other program- without erasing
> the file if you really want. Be prepared to properly handle data
> inconsistencies if you do so.
>
> Instead of restarting MimeDefang (and Sendmail) after a map update
> it's sufficient to run:
> md-mx-ctrl reread
>
> From the md-mx-ctrl(8) manpage:
>
> reread Forces mimedefang-multiplexor to kill all idle slaves,
> and terminate and restart busy slaves when they become
> idle. This forces a reread of filter rules.
>
> Regards,
>
> Kees.
>
> --
> Kees Theunissen.

Kees,

Instead of constantly rereading, I put into the bottom of
filter_initialize :

$oldmailidtime = (stat('/etc/mail/mailid.db'))[9];
$oldvariouttime = (stat('/etc/mail/variout.db'))[9];

and then in filter_end before I make use of the key, I do :

$newvariouttime = (stat('/etc/mail/variout.db'))[9];
if ($newvariouttime > $oldvariouttime) {
untie %variout;
tie %variout, "DB_File", "/etc/mail/
variout.db",
O_RDONLY;
$oldvariouttime = (stat('/etc/mail/
variout.db'))[9];
}

or

$newmailidtime = (stat('/etc/mail/mailid.db'))
[9];
if ($newmailidtime > $oldmailidtime) {
untie %mailid;
tie %mailid, "DB_File", "/etc/mail/
mailid.db",
O_RDONLY;
$oldmailidtime =
(stat('/etc/mail/mailid.db'))[9];
}


Problem solved, I can still use the sendmail "makemap" to create
my files, and
except for adding an "lc" to the $LookupRecipient, I think I have
things pretty well
working as wanted.

Still doesn't mean I don't want to know why changing the map
name, and
key from $1 to $&u made things go all wonky!

Thanks, Tuc