search by envelope-to field

[trunksy]

I'm getting spammed and I need to do a search in my mailbox by the field
"Envelope-to". Unforunately, Outlook 2007 doesn't seem to have that field
and won't let me create a custom field in the Advanced Search tool.

It's useless to do a search using the "To" field because it is forged and
different every time. The only field that matters is the "Envelope-to" field
as far as message delivery. Anyone know how to get Outlook 2007 to search
based on that field? I tried using alternate fields like BCC but no luck.
The exact name of the header field is "Envelope-to".

 

[VanguardLH]

I'm getting spammed and I need to do a search in my mailbox by the
field
"Envelope-to". Unforunately, Outlook 2007 doesn't seem to have that
field
and won't let me create a custom field in the Advanced Search tool.

It's useless to do a search using the "To" field because it is
forged and
different every time. The only field that matters is the
"Envelope-to" field
as far as message delivery. Anyone know how to get Outlook 2007 to
search
based on that field? I tried using alternate fields like BCC but no
luck.
The exact name of the header field is "Envelope-to".

Envelope-to is not a standard header defined in "Internet Message
Format", RFC 2822. Some mail servers will add them at *final*
delivery but it not to be added to messages during transit.

You could define a rule to look for a string in the message headers,
like "Envelope-to: <string>". You cannot define the rule to look for
a specific value for that non-standard header. You can have the rule
look for the header + string value.

 

[trunksy]

Envelope-to is not a standard header defined in "Internet Message
Format", RFC 2822. Some mail servers will add them at *final*
delivery but it not to be added to messages during transit.

Spammers don't quite play by the RFC rules as is evident by their forging
and using non standard headers to complete their means of email tracking
contermeasures and affecting mail delivery.

You could define a rule to look for a string in the message headers,
like "Envelope-to: <string>". You cannot define the rule to look for
a specific value for that non-standard header. You can have the rule
look for the header + string value.

Using a rule to look for a string that included the header worked for me.
Thanks.

 

[VanguardLH]

in message

Spammers don't quite play by the RFC rules as is evident by their
forging
and using non standard headers to complete their means of email
tracking
contermeasures and affecting mail delivery.

Except for the Received headers (and a few others) that are added by
the mail hosts in the route between the sender and recipient, all the
other headers can be forged simply because they are not headers that
were added by the mail hosts. There were *data* that were included in
the e-mail. Whatever you put in the To, Cc, and Bcc fields in the UI
for your e-mail client *might* be used by the e-mail client to
generate RCPT-TO commands, one for each recipient. That is not how
listservers or bulk mailers work. They couldn't give a gnat's fart
about the data within an e-mail to determine who gets it. They use a
separate list to generate the RCPT-TO commands. The same for the
return-path headers, like From and Reply-To. Those are data that the
e-mail program sends in the DATA command. The e-mail client compiles
a list of recipients, sends a RCPT-TO command for each recipient, and
then issues the DATA command to send the e-mail (which contains the
To, Cc, From, Subject headers that the *user* specified).

The only time the true sender is known is within the mail session
established between the sending and receiving mail hosts. Every host
knows the IP address of who connects to it. The receiving mail host
should reject messages DURING the mail session. If the message is
delivered after the mail session is over, like when using a redirect
or forwarding service or by users sending bogus bounces, they cannot
reject the message. They can only send a *new* message based on the
return-path headers that the *sender* specified in the *data* of their
message, and obviously this sender-specified data can be falsified.

SMTP was written some 20+ years ago and based on a trust model that
has become evident can be subverted. SPF got developed to let mail
hosts know the true sender of an e-mail but some users think they can
use those headers to validate the sender. Nope, those headers are
only valid between mail hosts that can do the validation DURING the
mail session. In fact, some spammers will insert bogus SPF headers
hoping to mislead recipients that SPF actually got used to validate
the sender. A lot of information is lost by the time the recipient
get e-mail and why the [potentially] most effective anti-spam methods
are implemented at the mail server.

So what help does the Envelope-To header provide in fighting spam? It
is added only by the mail host at the destination (i.e., by YOUR mail
server). Obviously you know the recipient was to you whether or not
you are listed in the *data* fields of To and Cc. If Bcc was used,
you still know that you were specified as the recipient so the
Envelope-To header is superlfuous. You got the e-mail so you already
know you were listed as a recipient.