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