SetEnvelopeTo


#1

There’s been some confusion as to what SetEnvelopeTo in sendmail is
useful for. MTAs suck as sendmial seperate the notion of
the Envelope To and the Header recipients. SetEnvelopeTo is a "trick"
header that will be removed by RT:::Action::SendEmail before sending
and, If present, used to determine the actual envelope recopeints.
If it’s not present, the regular to:, cc: and bcc: headers.

Does that clear things up a bit?
jesse

jesse reed vincent – jrvincent@wesleyan.edujesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Any e-mail sent to the SLA will immediately become the intellectual property
of the SLA and the author of said message will enter into a period of
indentured servitude which will last for a period of time no less than seven
years.


#2

the Envelope To and the Header recipients. SetEnvelopeTo is a "trick"
header that will be removed by RT:::Action::SendEmail before sending
and, If present, used to determine the actual envelope recopeints.
If it’s not present, the regular to:, cc: and bcc: headers.

I think I understood this after a while. See my comments in the most
recent version of SendEmail.pm :slight_smile:

Tobias Brox
aka TobiX
+47 22 925 871


#3

the Envelope To and the Header recipients. SetEnvelopeTo is a "trick"
header that will be removed by RT:::Action::SendEmail before sending
and, If present, used to determine the actual envelope recopeints.
If it’s not present, the regular to:, cc: and bcc: headers.

I think I understood this after a while. See my comments in the most
recent version of SendEmail.pm :slight_smile:

  • -Quoting tobix from the recent SendEmail.pm
  • override
  • either the SetRecipients method or the SetTo, SetCc, etc methods.

Why are you introducing the SetRecipients? SetTo setCc and SetBcc
work as well and are more flexible

  • Envelope-To is not mentionated in RFC822, and might not work with all
  • mailers. Actually TobiX is not sure it will work with any mailer at
  • all.

right. because this is all to be handled transparently inside SendEmail.pm
Every MTA I’ve ever used has allowed the specifcation of the Envelope To
when invoking it. sendmail takes them on the commandline. Mail::Internet->smtpsend takes them as an argument.


Tobias Brox
aka TobiX
+47 22 925 871


Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

jesse reed vincent – jrvincent@wesleyan.edujesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
I admit that X is the second worst windowing system in the world, but all the
others I’ve used are tied for first.


#4

Why are you introducing the SetRecipients? SetTo setCc and SetBcc
work as well and are more flexible

I think it might be better to override SetRecipients sometimes. The To,
Cc and Bcc headerlines aren’t always independent from each other. I’ll
examplify it pretty soon (I just have some debugging to do … :slight_smile:

right. because this is all to be handled transparently inside SendEmail.pm

Updated:

(…)
The EnvelopeTo functionality is not implemented as for now.
(…)


#5

I think it might be better to override SetRecipients sometimes. The To,
Cc and Bcc headerlines aren’t always independent from each other. I’ll
examplify it pretty soon (I just have some debugging to do … :slight_smile:

Ok. perhaps what we should be doing is calling SetRecipients which calls
the SetTo, SetCc, SetBcc and SetEnvelopeTo for you. that might make it all
easier to subclass

Updated:
The EnvelopeTo functionality is not implemented as for now.

You know, you’re usually so good at reading my mind that I forget that you
can’t do it all the time :slight_smile:

jesse reed vincent – jrvincent@wesleyan.edujesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Any e-mail sent to the SLA will immediately become the intellectual property
of the SLA and the author of said message will enter into a period of
indentured servitude which will last for a period of time no less than seven
years.


#6

Ok. perhaps what we should be doing is calling SetRecipients which calls
the SetTo, SetCc, SetBcc and SetEnvelopeTo for you. that might make it all
easier to subclass

Sounds nice to me, I’ll fix it that way.

Tobias Brox
aka TobiX
+47 22 925 871


#7

Cool!

Perhaps, SetRecipients should take

%args = ( To => undef,
Cc => undef,
Bcc =>undef,
EnvelopeTo => undef);

and do the right thing with setting envelope-to to the sum of To,Cc and Bcc.

At some point, we should also deal with stripping out the actor’s email
from the to/from/cc. but maybe that should be configurable based on
a “notify me on my own messages.” flag in the user’s account.On Thu, Apr 06, 2000 at 08:20:39PM +0200, Tobias Brox wrote:

Ok. perhaps what we should be doing is calling SetRecipients which calls
the SetTo, SetCc, SetBcc and SetEnvelopeTo for you. that might make it all
easier to subclass

Sounds nice to me, I’ll fix it that way.


Tobias Brox
aka TobiX
+47 22 925 871

jesse reed vincent – jrvincent@wesleyan.edujesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
’“As the company that brought users the Internet, Netscape is now inviting
the more than 60 million people who have used our client software to
’tune up’ and upgrade to Netscape Communicator,” said Mike Homer,
senior vice president of marketing at Netscape.’ Sometimes I wonder.


#8

Perhaps, SetRecipients should take

%args = ( To => undef,
Cc => undef,
Bcc =>undef,
EnvelopeTo => undef);

and do the right thing with setting envelope-to to the sum of To,Cc and Bcc.

I think that is a bit out of the scope of “my” SetRecipients. The idea is
to allow the logic to be easily separated. That is, finding the right
To, Cc, Bcc and EnvelopeTo. Maybe I’m wrong.

Here’s from the file I’m working at:

POD:

If you want to set the recipients of the mail to something other than
the addresses mentioned in the To, Cc, Bcc and EnvelopeTo headers in
the template, you should subclass RT::Action::SendEmail and override
either the SetRecipients method or the SetTo, SetCc, etc methods (see
the comments for the SetRecipients sub).

Comments & sub:

The specialized SetRecipients sub should find out whom to send the

message to, and then set the header fields.

If SendEmail is called rather than a subclass, the receipients have

to be set by the template.

There is three ways to override this (well, more ways … you could

of course add the logic to a specialized prepare or commit or

something … but that’s not considered a good way to do it anyway).

1: Override SetRecipients to set the header fields (to, cc, bcc) and

eventually call SetEnvelopeTo

2: Override SetRecipients to set the hash elements $self->{To}, {Cc}

and {Bcc}, and then call SUPER::SetRecipients.

3: Override SetTo, SetCc and/or SetBcc.

sub SetRecipients {
$self->SetTo();
$self->SetCc();
$self->SetBcc();
$self->SetEnvelopeTo();
}


#9

Perhaps, SetRecipients should take

%args = ( To => undef,
Cc => undef,
Bcc =>undef,
EnvelopeTo => undef);

and do the right thing with setting envelope-to to the sum of To,Cc and Bcc.

I think that is a bit out of the scope of “my” SetRecipients. The idea is
to allow the logic to be easily separated. That is, finding the right
To, Cc, Bcc and EnvelopeTo. Maybe I’m wrong.

Ok. we’ll leave it for now, but before we roll 2.0, I think I may want
to simplify this some. Rather than setting $self->{‘To’} to an address
and then calling $self->SetTo, perhaps we should be calling
$self->SetTo(“address”); I think this is my fault from way back.

Here’s from the file I’m working at:

POD:

If you want to set the recipients of the mail to something other than
the addresses mentioned in the To, Cc, Bcc and EnvelopeTo headers in
the template, you should subclass RT::Action::SendEmail and override
either the SetRecipients method or the SetTo, SetCc, etc methods (see
the comments for the SetRecipients sub).

Comments & sub:

The specialized SetRecipients sub should find out whom to send the

message to, and then set the header fields.

If SendEmail is called rather than a subclass, the receipients have

to be set by the template.

There is three ways to override this (well, more ways … you could

of course add the logic to a specialized prepare or commit or

something … but that’s not considered a good way to do it anyway).

1: Override SetRecipients to set the header fields (to, cc, bcc) and

eventually call SetEnvelopeTo

2: Override SetRecipients to set the hash elements $self->{To}, {Cc}

and {Bcc}, and then call SUPER::SetRecipients.

3: Override SetTo, SetCc and/or SetBcc.

sub SetRecipients {
$self->SetTo();
$self->SetCc();
$self->SetBcc();
$self->SetEnvelopeTo();
}

jesse reed vincent – jrvincent@wesleyan.edujesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
After all, it’s not every day you meet up with an evil power
-M. Bulgakov


#10

Ok. we’ll leave it for now, but before we roll 2.0, I think I may want
to simplify this some.

I also think we’ll leave it as it is now, even though it’s messy.

We actually need to check up the receipients in the IsApplicable sub! For
2.0, we need to check if there really are receipients to a mail (I’ve
added some hacks that terminate prepare if there aren’t receipients, but
it’s no good since we already has passed quite some overhead parsing the
templates).

Tobias Brox
aka TobiX
+47 22 925 871


#11

Cool!

Perhaps, SetRecipients should take

%args = ( To => undef,
Cc => undef,
Bcc =>undef,
EnvelopeTo => undef);

and do the right thing with setting envelope-to to the sum of To,Cc and Bcc.

Why? Setting envelope-to to a union of To, Cc and Bcc is precisely what
any RFC822 compliant MTA does, so why should we duplicate it? OTOH, if we
are managing the envelope-to, then why do we need Bcc, since the MTA will
delete that header, and ignore the others?

Charlie Brady
Aurema Pty Ltd
PO Box 305, Strawberry Hills, NSW 2012, Australia
Email:charlieb@aurema.com, Tel: +61 2 9698 2322, Fax: +61 2 9699 9174
"I think it would be a good idea." Gandhi, on Western Civilisation.