Re: Feature Request: envelope scanning
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - 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
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Feature Request: envelope scanning
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
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 pgpyoUyxC691m.pgp Description: PGP signature
Re: Feature Request: envelope scanning
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
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Feature Request: envelope scanning
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
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
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
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.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: Feature Request: envelope scanning
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.
