You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Joe Flowers <fl...@social.chass.ncsu.edu> on 2006/10/25 20:35:07 UTC
Feature Request: envelope scanning
Hey guys,
If I pre-pend a message's Envelope to it's Body, can Spamassassin do
anything useful with it?
Joe
Re: Feature Request: envelope scanning
Posted by Theo Van Dinter <fe...@apache.org>.
On Sat, Oct 28, 2006 at 11:41:48AM -0400, Joe Flowers wrote:
> I'm not sure what you are talking about Theo. Sorry.
I was talking about SMTP.
> Below is an envelope example from a Spam email, at least an envelope
> from my mail system.
> ---------------------------
> D1161764311
> Fwxbophlw@bgce.com -
> A3548708497
> X1
> Lwallwk wallwk 12
> ---------------------------
That's nothing like an envelope in other MTAs. It looks more like the data
found in a MTA's message queue file. But anyway...
To answer your original question, no, putting that at the top of the
message passed to SA will not be helpful since as far as SA is concerned,
you'll be sending in a message with no headers (the above looks like a
body, so SA treats it that way).
> I assume the "wxbophlw@bgce.com" is useful to SA.
> Is there a better form I can put this in before pre-pending to the
> message body? Also, currently, the message body comes after an blank
If it was added in a standard format, that would be useful. The two
recommended methods are to include the address in the Received header
when the MTA adds it, or adding a X-Envelope-From header.
> line. i.e., there's a blank line between the "envelope" and the message
> body. The reason for prepending a lot of the garbage though is to help
> track the message thru the system. I assume this garbage won't hurt or help?
Definitely hurt in that format.
--
Randomly Selected Tagline:
"I've been told to wait 1 hour after eating to go swimming... but fish eat,
and then they swim immediately." - Richard Jeni
Re: Feature Request: envelope scanning
Posted by Joe Flowers <fl...@social.chass.ncsu.edu>.
I'm not sure what you are talking about Theo. Sorry.
Below is an envelope example from a Spam email, at least an envelope
from my mail system.
I assume the "wxbophlw@bgce.com" is useful to SA.
Is there a better form I can put this in before pre-pending to the
message body? Also, currently, the message body comes after an blank
line. i.e., there's a blank line between the "envelope" and the message
body. The reason for prepending a lot of the garbage though is to help
track the message thru the system. I assume this garbage won't hurt or help?
Thanks!
Joe
---------------------------
D1161764311
Fwxbophlw@bgce.com -
A3548708497
X1
Lwallwk wallwk 12
---------------------------
Theo Van Dinter wrote:
> On Wed, Oct 25, 2006 at 02:35:07PM -0400, Joe Flowers wrote:
>
>> If I pre-pend a message's Envelope to it's Body, can Spamassassin do
>> anything useful with it?
>>
>
> It depends what you mean by "a message's envelope". If you mean add in
> standard headers for MAIL FROM and RCPT TO, then sure, go ahead and SA will
> use them for different things (RTM). If you mean "prepend the SMTP command
> lines for MAIL FROM and RCPT TO", you'll be sending garbage into SA.
>
>
Re: Feature Request: envelope scanning
Posted by Theo Van Dinter <fe...@apache.org>.
On Wed, Oct 25, 2006 at 02:35:07PM -0400, Joe Flowers wrote:
> If I pre-pend a message's Envelope to it's Body, can Spamassassin do
> anything useful with it?
It depends what you mean by "a message's envelope". If you mean add in
standard headers for MAIL FROM and RCPT TO, then sure, go ahead and SA will
use them for different things (RTM). If you mean "prepend the SMTP command
lines for MAIL FROM and RCPT TO", you'll be sending garbage into SA.
--
Randomly Selected Tagline:
"I believe in getting into hot water; it keeps you clean." - G. K. Chesterton
Re: Feature Request: envelope scanning
Posted by "Eric A. Hall" <eh...@ehsco.com>.
On 10/25/2006 5:46 PM, Ken A wrote:
> It should be mentioned that envelope To: is not there for a reason. :-(
> Including it in the header will remove the privacy enabled by Bcc
This is true--BCC will be made entirely pointless if the envelope
recipients are irreversibly pasted into the message.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Feature Request: envelope scanning
Posted by Joe Flowers <fl...@social.chass.ncsu.edu>.
David B Funk wrote:
> When the milter is passing the message to spamd, it is easy to add
> synthesized headers (such as 'Return-Path:' & 'X-Envelope-To:') to pass
> envelope addresses to SA (that's what I did with the milter that I use).
>
Still, pre-pending is 10x easier than inserting.
Re: Feature Request: envelope scanning
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Wed, 25 Oct 2006, Joe Flowers wrote:
> Ken A wrote:
> > It should be mentioned that envelope To: is not there for a reason.
> > :-( Including it in the header will remove the privacy enabled by Bcc,
> > so if you have privacy considerations to worry about, you might think
> > twice.
>
> I pre-pend the envelope to a copy of the message and then send the copy
> thru SA. The copy is discarded, but the SA score is added to the header
> of the original and then sent on. I'm hoping that somehow SA could work
> something like this in as a feature.
>
> Joe
That is almost exactly how a sendmail-SA-milter works. It takes a copy
of the message from the SMTP stream, passes it to spamd, parses the SA
results, then sends commands back to sendmail telling it how to
modify the original message (add X-Spam headers, modify the Subject
header contents, etc).
When the milter is passing the message to spamd, it is easy to add
synthesized headers (such as 'Return-Path:' & 'X-Envelope-To:') to pass
envelope addresses to SA (that's what I did with the milter that I use).
Doesn't require any modifications to SA, just the method you use
to integrate SA into your mail system.
Theoretically you could write a wrapper to spamc to do something
similar except that spamc is not usually provided the envelope
addresses.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Feature Request: envelope scanning
Posted by Joe Flowers <fl...@social.chass.ncsu.edu>.
Ken A wrote:
> It should be mentioned that envelope To: is not there for a reason.
> :-( Including it in the header will remove the privacy enabled by Bcc,
> so if you have privacy considerations to worry about, you might think
> twice.
I pre-pend the envelope to a copy of the message and then send the copy
thru SA. The copy is discarded, but the SA score is added to the header
of the original and then sent on. I'm hoping that somehow SA could work
something like this in as a feature.
Joe
Re: Feature Request: envelope scanning
Posted by Ken A <ka...@pacific.net>.
Eric A. Hall wrote:
> On 10/25/2006 2:35 PM, Joe Flowers wrote:
>
>> If I pre-pend a message's Envelope to it's Body, can Spamassassin do
>> anything useful with it?
>
> At a minimum you can use the envelope recipient(s) to do some kinds of
> spam-trap filtering (eg, is the message addressed to a spamtrap and me).
> You can use the envelope sender to do some kinds of whitelisting too (such
> as whitelisting your aunt at yahoo even if the you have the whole yahoo
> domain otherwise blacklisted, or whitelisting a mailing list "sender"). My
> LDAPfilter plugin (http://www.ehsco.com/misc/ldapfilter/) uses them for
> these kinds of purposes.
>
> Other possibilities exist too. Envelope sender can be used for some SPF
> filters that aren't currently done, for example.
>
> The first problem is that there is no standard header field, and in the
> case of envelope recipient(s) where there can be multiple entries, there
> is no standard for the field data. I use X-Envelope-To and X-Envelope-From
> with typical RFC822 address syntaxes (no "real name" blob, etc), but only
> because I had nothing else to use and that structure seems to be the most
> obvious and least harmful.
>
> Another consideration is that they have to be created by the MTA, and
> spamassassin doesn't have possession of the envelope data so it can't
> create them. In my case I have to make postfix generate them in order for
> them to be usable, and the LDAPfilter plugin has .cf options that point to
> the header fields in questions (eg, "ldapfilter_env_from_header")
>
> But yeah, if they are provided and if there is a way to tell spamassassin
> where to look, they are very useful.
It should be mentioned that envelope To: is not there for a reason. :-(
Including it in the header will remove the privacy enabled by Bcc, so if
you have privacy considerations to worry about, you might think twice.
envelope data is available to milters, so SA running via a milter could
take this into consideration without including it in the header. Not
sure if it does, but other milters certainly do.
Ken A.
Pacific.Net
Re: Feature Request: envelope scanning
Posted by Kelson <ke...@speed.net>.
Mark Martinec wrote:
> If scanning at the MTA level with amavisd-new, a synthetic Return-Path
> is prepended to a copy of a message that is given to SA for examination.
> Much like David B Funk says a sendmail-SA-milter does.
MIMEDefang does this as well. It synthesizes Received and Return-Path
when passing the message to SpamAssassin.
There was some discussion a month or so back on providing a way for
filters to add custom headers to the SA call, so you could do things
like X-Envelope-To. Two people posted the methods they used, but the
author wasn't quite satisfied with either method. Last I remember
reading, he said he was looking into another way to do it.
--
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: Feature Request: envelope scanning
Posted by Mark Martinec <Ma...@ijs.si>.
> > For envelope sender there is a standard header: Return-Path
>
> Return-Path is supposed to be added when the message is placed in the
> mailstore (ie, last hop, after the transfer network). Since I do scanning
> at the MTA level before delivery, I don't have Return-Path yet.
If scanning at the MTA level with amavisd-new, a synthetic Return-Path
is prepended to a copy of a message that is given to SA for examination.
Much like David B Funk says a sendmail-SA-milter does.
There is no point using some nonstandard header field like X-Envelope-From,
when Return-Path is there for just this purpose.
spamc could be doing the same thing when it prepares a copy for spamd.
It just needs a command line option to obtain envelope information
from a caller (when available).
Mark
Re: Feature Request: envelope scanning
Posted by "Eric A. Hall" <eh...@ehsco.com>.
On 10/25/2006 7:15 PM, Mark Martinec wrote:
> For envelope sender there is a standard header: Return-Path
Return-Path is supposed to be added when the message is placed in the
mailstore (ie, last hop, after the transfer network). Since I do scanning
at the MTA level before delivery, I don't have Return-Path yet.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Feature Request: envelope scanning
Posted by Mark Martinec <Ma...@ijs.si>.
Eric A. Hall wrote:
> Other possibilities exist too. Envelope sender can be used for some SPF
> filters that aren't currently done, for example.
> The first problem is that there is no standard header field, and in the
> case of envelope recipient(s) where there can be multiple entries, there
> is no standard for the field data. I use X-Envelope-To and X-Envelope-From
For envelope sender there is a standard header: Return-Path
RFC 2821
4.4 Trace Information
...
When the delivery SMTP server makes the "final delivery" of a
message, it inserts a return-path line at the beginning of the mail
data. This use of return-path is required; mail systems MUST support
it. The return-path line preserves the information in the <reverse-
path> from the MAIL command.
Envelope recipient information can be contained in trace headers
(Received, subfield FOR). In case of multiple recipients this may
violate sender privacy, but when there is only one envelope recipient
present this is not of concern, such envelope recipient address
may be included in a Received header field.
Mark
Re: Feature Request: envelope scanning
Posted by "Eric A. Hall" <eh...@ehsco.com>.
On 10/25/2006 2:35 PM, Joe Flowers wrote:
> If I pre-pend a message's Envelope to it's Body, can Spamassassin do
> anything useful with it?
At a minimum you can use the envelope recipient(s) to do some kinds of
spam-trap filtering (eg, is the message addressed to a spamtrap and me).
You can use the envelope sender to do some kinds of whitelisting too (such
as whitelisting your aunt at yahoo even if the you have the whole yahoo
domain otherwise blacklisted, or whitelisting a mailing list "sender"). My
LDAPfilter plugin (http://www.ehsco.com/misc/ldapfilter/) uses them for
these kinds of purposes.
Other possibilities exist too. Envelope sender can be used for some SPF
filters that aren't currently done, for example.
The first problem is that there is no standard header field, and in the
case of envelope recipient(s) where there can be multiple entries, there
is no standard for the field data. I use X-Envelope-To and X-Envelope-From
with typical RFC822 address syntaxes (no "real name" blob, etc), but only
because I had nothing else to use and that structure seems to be the most
obvious and least harmful.
Another consideration is that they have to be created by the MTA, and
spamassassin doesn't have possession of the envelope data so it can't
create them. In my case I have to make postfix generate them in order for
them to be usable, and the LDAPfilter plugin has .cf options that point to
the header fields in questions (eg, "ldapfilter_env_from_header")
But yeah, if they are provided and if there is a way to tell spamassassin
where to look, they are very useful.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/