[spambayes-bugs] [ spambayes-Bugs-1535214 ] Mail without a To: field not sent to Inbox
SourceForge.net
noreply at sourceforge.net
Mon Aug 7 23:53:34 CEST 2006
Bugs item #1535214, was opened at 2006-08-06 12:20
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=498103&aid=1535214&group_id=61702
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: jljacobs (jljacobs)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mail without a To: field not sent to Inbox
Initial Comment:
NOted that spamBayes classified mail as ***Ham*** AND
it does show up properly as Ham in the review of
database BUT is ***NOT*** passed on to the Inbox (OE)
and therefore is totally missing as new mail, either
spam, unsure or ham.
Until today after using SB for more than a year I
realized that a good part of my mail was missing but
only readable in the reviews of SpamBayes mail.
So far NO spam arrives without a To: field in the body
so that this is not an unresolvable problem. (BTW, the
biggest new spam problem is 'image based' spam, which
is not easily dealt with by text based statistical
methodology.)
I can bypass this (and as of today, 8/6/06) have in OE
by setting up an OI Microsoft "rule" which is executed
prior to allowing SpamBayes inputs. This hack sends
such erroneous mail to the Inbox despite SpamBayes
proper classification as Ham but not processing
proxying it properly to the Inbox.
I can provide any file that the developer(s) might want
but with considerable annotation as I personally know
what is Ham vs. Spam.
--- John
----------------------------------------------------------------------
>Comment By: Tony Meyer (anadelonbrin)
Date: 2006-08-08 09:53
Message:
Logged In: YES
user_id=552329
BTW, I have verified that this does indeed work (mail from
Apple Mail using only bcc (so there isn't a To: header) to
Outlook Express 6 (XP Home) using spambayes 1.0.4 and
spambayes 1.1a2 with the notate_to option set to unsure &
spam. With both, the message arrived correctly, with no To:
header.
You're now saying that the messages aren't received by
Outlook Express at all, so what we need is a copy of your
most recent log and to know what version of spambayes you
are using.
----------------------------------------------------------------------
Comment By: jljacobs (jljacobs)
Date: 2006-08-08 07:26
Message:
Logged In: YES
user_id=1569546
Tony ---
The issue is not random contrary to an my earlier statment
as I can see what is happening.
I received ***4*** msgs today from my associate in France.
Only ***one*** of them was pased thru to OE. The other three
have identical errors in the header.
(1) All come from a Mac with the header --- X-Mailer: Apple
Mail (2.746.2).
(2) All 4 have an X-Spambayes-Classification:ham. I repeat ham.
(3) The 3 that were not passed thru show 'to:none in the
X-Spambayes-Evidence header.
(4) The one that got was passed thru shows 'to:name:john l
jacobs in the evidence.
(5) The latter 'to:' evidence traces do not effect the
classification as Ham. I don't think that is the issue that
is causing SB to fail to pass this Ham onto OE.
(6) The only unique thing is that the singular msg that was
passed to OE has a "To:" header, in fact addressed to me.
The other 3 were sent using Bcc:, I believe in the senders
Apple Mail(er).
(7) The other 3 lack entirely the "To: header --- and the
evidence data shows that despite my guess that the evidence
noting this is irrelevant.
My config requires that the only 'spam' or 'unsure' be
appended to the "To:" header. (If Ham nothing is appended.
Since the three that were not passed thru to OE would not
have had anything appended, they being Hamn, I have to
conclude that the problem is that Spambayes, contrary to
your belief, does NOT pass thru msgs that completely lack a
"To:" header at least when the configuration would
***require*** the evaluation to be appended to that header
--- whether it would be or not.
This is a definitely a bug but I've not done any programming
in decades so am unable to analyze anything but the result
but it can replicate it or rather it replicates itself daily
with Apple Mail incoming from my associate.
And BTW, as you have said anything passed thru to OE would
be seen by OE and could be acted on by its 'Rules'. I am
incorrect in stating that I have a workaround in the
'Rules'. My first jump at this is logically and factually
impossible and does not work. I have deactivated ALL rules
at this point to exclude OE as the culprit here.
Here is the header of 1 of the 3 that did not get passed to
OE. Looking at this in webmail I am not sure that the entire
evidence section got "pasted" properly --- it looks shorter
than the original --- I hat web mail (!!!)
Anyway you will note the complete lack of a "To:" header.
The other 2 msgs are the same and were not passed to
OE............
Return-Path: <nygaston at mac.com>
Delivered-To: mailbox2 at speakeasy.net
Received: (qmail 22258 invoked by alias); 7 Aug 2006
06:23:11 -0000
Delivered-To: info at jljacobs.com
Received: (qmail 24167 invoked from network); 7 Aug 2006
06:23:11 -0000
Received: from smtpout.mac.com ([17.250.248.174])
(envelope-sender <nygaston at mac.com>)
by mail26.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP
for <info at jljacobs.com>; 7 Aug 2006 06:23:11 -0000
Received: from mac.com (smtpin08-en2 [10.13.10.153])
by smtpout.mac.com (Xserve/8.12.11/smtpout04/MantshX 4.0)
with ESMTP id
k776N7tF024876; Sun, 6 Aug 2006 23:23:07 -0700 (PDT)
Received: from [192.168.1.11]
(aputeaux-152-1-62-72.w82-120.abo.wanadoo.fr
[82.120.168.72]) (authenticated bits=0)
by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id
k776Mwdn004025;
Sun, 6 Aug 2006 23:23:00 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v746.2)
Message-Id: <8068EC86-D1D6-4943-9B80-C5EF17BD6ADE at mac.com>
Content-Type: multipart/mixed; boundary=Apple-Mail-120-530927214
From: Tom Gaston <nygaston at mac.com>
Subject: The Original Statue of Liberty was created in
France...Here,
in Lorraine.
Date: Mon, 7 Aug 2006 08:23:06 +0200
X-Mailer: Apple Mail (2.746.2)
X-Spambayes-Classification: ham
X-Spambayes-Spam-Probability: 0.00
X-Spambayes-Evidence: '*H*': 1.00; '*S*': 0.00;
'x-mailer:apple mail (2.746.2)': 0.03; 'received:10.13': 0.04;
'received:17': 0.04; 'received:17.250': 0.04;
'received:17.250.248': 0.04; 'received:mac.com': 0.04;
'received:smtpout.mac.com': 0.04; 'from:addr:nygaston': 0.04;
'from:name:tom gaston': 0.04; 'received:10.13.10': 0.05;
'message-id:@mac.com': 0.05; 'from:addr:mac.com': 0.07;
'received:192.168.1': 0.08; 'received:192.168.1.11': 0.09;
'content-type:multipart/mixed': 0.12;
'content-type:image/jpeg': 0.14;
'received:10.13.10.153': 0.16; 'subject:skip:F 10': 0.16;
'filename:fname piece:jpg': 0.19; 'received:10': 0.21;
'received:192.168': 0.26; 'received:192': 0.29;
'subject:The': 0.37;
'to:none': 0.61; 'subject:.': 0.67; 'charset:us-ascii': 0.69;
'received:com': 0.73; 'received:network': 0.81;
'subject:Original': 0.84; 'subject:created': 0.84;
'subject:was': 0.91;
'subject:,\n\t': 0.98
X-Spambayes-MailId: 1154931838
--Apple-Mail-120-530927214
Content-Transfer-Encoding: base64
Content-Type: image/jpeg; x-mac-type=4A504547; x-unix-mode=0644;
name="IMG_4811.jpg"
Content-Disposition: inline;
filename=IMG_4811.jpg
I do believe I have isolated what is happening here though I
do not have the skills any longer to examine the code.
Regards, John (414-255-7000)
----------------------------------------------------------------------
Comment By: Tony Meyer (anadelonbrin)
Date: 2006-08-07 14:25
Message:
Logged In: YES
user_id=552329
The body of a message is everything after the blank line
that separates the headers and body (see RFC2822). SMTP
servers are meant to *add* headers (to the DATA portion,
which is the only part that gets to the recipient). You
don't need any headers in a message, and SMTP isn't the only
way to deliver mail.
If there isn't a To: header and you are using the notate_to
option, then a To: header (containing only the notation) is
added.
Again, either mail gets to OE or it doesn't. If it doesn't
get there, then it doesn't matter what you do with rules,
the mail isn't there to be processed. Does the mail get to
OE or not?
If it doesn't, then please attach a log file for when this
happened and let us know which version of SpamBayes you are
using.
If the mail does arrive in OE, then I still don't understand
what the problem is here.
----------------------------------------------------------------------
Comment By: jljacobs (jljacobs)
Date: 2006-08-07 13:27
Message:
Logged In: YES
user_id=1569546
To: Tony Meyer
Let me define the SMTP 'body' as all the text that is not
entered by SMTP servers in transit. The 'To:', 'From:' and
'Subject:' fields have the same status as the rest of a msg
and none are even necessary to send mail. Try it by
connecting to any SMTP server and send a msg by entering the
SMTP commands (by brute force).
The 'Envelope' header is the part of a msg added by the
sending server and all intermediaries (of which their should
be none --- relays).
Now, proceeding here, there is a mailer used by an associate
(in France) which sends Bcc: mail without and 'body' To:
header whatsoever. My guess is that when that mail arrives
since there is no 'To:' body header there is no place for
Spambayes to add the 'ham', 'spam' or 'unsure' literals. The
lack of a 'To:' field results in the mail being in the
'Browse Messages' listing and can be read there but it is
NOT passed on to OE. It stops at the proxy.
Carrying this further, if I use the 'To":' header for
Spambayes to add the 'ham', 'spam' or 'unsure' result and I
get a msg that has no 'To:' header (whether you want to call
this the 'body' or the 'envelope' not being relevant, then
you tell me where Spambayes is to put the resultand literal
string. It simply does not exist in msgs from this mailer.
I am trying to get around this by using OE's 'rules' but
that is unreliable and really a cludge/hack.
It appears to me that Spambayes recognize the ^^^lack of the
field***, in this case the 'To:' field, which is configured
for the concatination of the 'ham', 'spam' or 'unsure'
string. If that is the configuration as mine is, Spambayes
does not know what to do and though the messages are
readable from browsing they get droped at that point and
asre not passed on.
I hope this clarifies the issue.
Regards, John
----------------------------------------------------------------------
Comment By: Tony Meyer (anadelonbrin)
Date: 2006-08-07 09:45
Message:
Logged In: YES
user_id=552329
This isn't particularly clear, sorry. The POP3 proxy lets
*all* mail through - either with an
X-Spambayes-Classification header, or an
X-Spambayes-Exception header if something went wrong.
Messages don't generally have a "To" in the body - this is
in the headers of the message. Perhaps that was what you
meant? Certainly every mail client I have seen (which
includes all of the major OS X ones) does include a "To"
header (but none include it in the body).
If you are able to fix this by using a rule in OE, then that
means that the mail *is* being delivered to Outlook Express
- or the rule would never see it.
Could you explain further what you mean?
----------------------------------------------------------------------
Comment By: jljacobs (jljacobs)
Date: 2006-08-07 08:13
Message:
Logged In: YES
user_id=1569546
John here again ----
I note that the lack of SB passing Ham onto OE's Inbox is
for me exclusively related to mail from a Mac where the
mailer totally fails to insert the "To:" in the msg body. I
am at a loss to deal with this as it does not always occur
but appears to happen randomly.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=498103&aid=1535214&group_id=61702
More information about the Spambayes-bugs
mailing list