Improving outlook rules

[Ammammata]

Hi there

I'd like to create a rule that forwards all mails received from a domain to
a short list of recipients, excluding those that are already in To: or Cc:

I gave a look to the rules, from Outlook 2010 to 2019, but this is not
(yet) possible unless, I presume, I start coding some VBA to be executed on
each mail that comes in.

Since I'm lacking experience in this environmnet (I usually work a little
on Access/Excel) I'd like to get some basic tips to start, i.e. how to set
the code to be executed on "incoming mail event", how to get the sender
mail address and all the recipients, how to forward the mail I'm examining,
adding the missing people. If you have some sample code I'll (try to) adapt
it to my needs.

Thank you in advance
Giovanni

--
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........

[Ammammata]

Il giorno Tue 26 Oct 2021 02:20:52p, *Ammammata* ha inviato su
microsoft.public.outlook il messaggio
news:XnsADCF91F67EE74am...@127.0.0.1. Vediamo cosa ha
scritto:

> If you have some sample code I'll (try to) adapt
> it to my needs.
>

i.e.
http://www.vboffice.net/en/developers/
I'm currently working on this

[VanguardLH]

Ammammata <amma...@tiscalinet.it> wrote:

> I'd like to create a rule that forwards all mails received from a
> domain to a short list of recipients, excluding those that are
> already in To: or Cc:
>
> I gave a look to the rules, from Outlook 2010 to 2019, but this is
> not (yet) possible unless, I presume, I start coding some VBA to be
> executed on each mail that comes in.

It's been a couple years since I last used MS Outlook. You can't define
a rule that looks for "sender contains <string>" and specify the domain
as the argument string? I would try to include the at-sign, so the rule
doesn't fire on the substring being in the username. Examples are:

sender contains @domain.

I'd end the string with the period to be sure you specify the correct
domain, not trying to specify "@somedomain" but ending up firing on
"@somedomainother". You want to specify a domain, not a substring that
could be in the domain. "@somedomain." would eliminate firing on
"@somedomainother."

If the at-sign canot be included, I would include the TLD (top-level
domain; e.g., .com, .org, .net) in the domain, as in:

sender contains domain.tld

Some domains even have a ccTLD (country code TLD), like .net.uk. I'd
use as much of the domain as possible to ensure the rule fires on the
correct domain, like:

sender contains @domain.
sender contains domain.tld
sender contains domain.tld.cctld

I don't remember if the rule condition was "sender contains" or "with
specific words in the sender's address".

Also, the rule will look at the SMTP sender, not the comment in the From
header. The From header has 2 tokens: comment (usually a name, but can
be any string) and addrspec (usually the sender's e-mail address).

From: comment <addrspec>

like:

From: Ammammata <amma...@tiscalinet.it>
'-- comment '-- addrspec (SMTP address)

For forwarding the message, you might want to create a group contact
used for the recipients to which the message gets forwarded. Then you
can edit the group contact instead of editing the rule.

You would add the the above rule "When the message arrives", and select
to "Redirect message to".

Rules should work fine. First look at what rules and conditions for
them along with available actions that are available up on the server in
your account. Server-side rules will execute whether your local client
is running or not, or whether your computer is powered on or off.
Different e-mail providers have varying robustness in their rules set.
Gmail sucks for defining rules, because they are really search criteria,
and Google is well known for using fuzzy logic with their searches.
Hotmail/Outlook.com have better rules. For example, in my Hotmail
account, I can define the following rule:

Name: Test
Condition: Sender address includes @domain.tld
Action: Forward to contactName

They also added the "Stop processing more rules" option. When the rule
fires, no subsequent other rules are exercised against the same message.
Without this option, multiple rules can exercise against the same
message; that is, you are OR'ing multiple rules on a message, and this
can have side benefits. Hotmail lets you serialize (order) your rules,
so you know which exercise first and which exercise last. This is
important to know the flow of a message through your rules to avoid
unwanted side effects (a rule exercised that you don't want to get
exercised after a prior rule made an action). For example, if your rule
deleted a message, you probably don't care to run other rules on the
same message, like trying to move it into a folder. If you want to move
some messages into a folder, the 'move' rule should appear ahead of the
'delete' rule, and each should use the "Stop processing more rules"
option. If you applied both, you'd move the message into another
folder, and then delete it (which moves it to the Trash folder).

OR'ing of multiple rules is accomplished by not using "Stop processing
more rules", so multiple rules get exercised on the same message.
AND'ing of rules is accomplish within a rule by adding multiple
conditions in the rule.

You might want to reconsider whether you forward the message, or forward
it as an attachment. Forwarding is actually creating a new message
where the original is embedded in the new message. The forwarded
message only show the content of the message, and few of its headers
(Date, From, etc). If you forward as attachment, the recipient gets a
full copy of the message: body and full headers.

Oops, I notice you want to exclude forwarding the message to recipients
already listed in the To or Cc headers. The same applies when defining
rules in your local e-mail client (Outlook). However, client-side rules
can only fire when the local client is running (which also means the
computer on which the client runs must be powered up, the OS ready, and
no crashes later). While you can add multiple conditions with a rule
(AND'ing them within a rule), the choices are limited, especially when
you're trying to effect a NOT operator, like:

sender contains <string1>
AND NOT To contains (<string2a> OR <string2b> OR <string2c>)
AND NOT Cc contains (<string3a> OR <string3b>)

For server-side rules in Hotmail/Outlook.com, the selection of negative
conditions is very limited (just 1), like:

I'm not on the To line

Missing is a rule condition of "<contactList> not in the To or Cc line".
You might be stuck with using a VBA macro when needing to employ
complicated rules beyond what the rule set permits in the client (or
webmail client). While the server-side rule set for Hotmail is very
limited for negative rules, I don't remember all the rule conditions
available in the Outlook local client. There are other newsgroups that
discuss VBA programming, like microsoft.public.outlook.program_vba, but
they have so little traffic that you might get stuck having to inquire
over at the web-based Microsoft Answers forums.

For using just rules, the only scheme that comes to my mind is using
OR'ed rules (disable the "Stop processing" option in each rule until the
last one) that keep changing a flag on a message, and then test the
resultant flag on the message to see if it gets forwarded, like:

sender contains @domain.tld then importance = high [no stop]
to recipient(s) then importance = low [no stop]
importance = high then forward to receipient(s) [stop]

You'd be using the importance flag to toggle on conditions where sender
matches but recipients don't include some recipients. However, if any
sender ever uses the importance flag (a header) then toggling importance
won't work. The only flags that can the tested in a condition of a rule
and also specified in the action of a rule are importance and
sensitivity (for a Hotmail.com rule). Also, I don't know if the "to"
filter tests on just the recipient(s) in the To header, or includes the
recipients in both the To and Cc headers. You're basically OR'ing
multiple rules that change the state of a flag, and lastly testing the
resultant state of the flag, as in:

if criteria1 then flag = Yes
if criteria2 then flag = No
if criteria3 then flag = No
if flag = Yes then someaction

A major problem is that the message might've used Bcc (Blind Carbon
Copy). That means you will never see who was listed in the Bcc header,
because it really isn't a header. When sending a message, the client
aggregates the recipients listed in the To, Cc, and Bcc *fields* within
its new message compose window. If the sender had 2 in To, 1 in Cc, and
7 in Bcc, you would only know about the 3 recipients in the To and Cc
headers (which the client actually adds as headers), and nothing about
the additional 7 recipients (the Bcc header never exists in a message).
For each recipient in the aggregate list of To, Cc, and Bcc recipients,
the client issues a separate RCPT-TO command to the SMTP server. Then
the client follows with the DATA command to send 1 copy of the message
to the server. So, for the example above, the client would issue 10
RCPT-TO commands followed by 1 DATA command. At your end, all you can
see are the 3 recipients in the To and Cc headers, and *none* of the
recipients that were in the Bcc field (not a header) when the sender
composed their message. Bcc means *BLIND* carbon copy. The recipient
is blind to any recipients that were Bcc'ed.