Gene Heskett wrote:
Further reading on fetchmail tells me that it hands the incoming mail
off to sendmail via stuffing it into port 110. Datapoint as I try to
get my head around the mechanics of this.
Er, I think you mean "..stuffing it into port 25.". Port 110 is where
fetchmail connects to on the *other* side to download your mail via
POP3. IIRC fetchmail also has a mode of operation where it feeds
directly to procmail rather than feeding a local MTA; but I can't
comment further as I've never used (or had need of <g>) fetchmail.
It is sendmail then that listens on port 110 and writes to
the /var/spool/mail/username file. Datapoint again.
> So there is a potential place to put a |spamc| is there not?, between
> fetchmail and port 110? A hack to fetchmail maybe? Datapoint.
sendmail typically uses procmail to actually write to the mailbox, and
it's very well-documented how to call SpamAssassin from a procmail
recipe. Aside from a great deal of other stuff I do to my mail before
stuffing it into a server-side mail folder, this is what I've used since
I started using SA, and I've never had trouble unless I was making
changes somewhere that affected how I might call SA. (Switching from
TCP socket to Unix socket, for instance...)
The easiest next step for you is probably to look for procmail in the SA
docs, and put the appropriate bits in your ~/.procmailrc file. To start
with, you might want to just have SA tag mail, and leave out the extra
procmail bits that actually file the tagged mail in a spam folder.
So it appears that wherever spamc is inserted into the path, it must be
presented with a single message complete with an EOF indicator of come
kind.
Yep. Doing this through the program that actually writes the message to
the mailbox is normally the simplest way to do so.
Looking at the src file, it doesn't appear there is a quick,
dirty, and 100% dependable way to filter the output of the cat command
and break it up into one stream per message. But I haven't ran a
tcpdump to see how its formatted on the network traffic yet.
Formatting on the wire (POP3 or SMTP) will be different (slightly) than
storage in an mbox mail folder. <g>
The only
thing I can see is linefeed,linefeed,From and since theres no way to
stop me from doing it in a message I send, it doesn't look that
reliable to me.
Most delivery agents actually watch for that, and prefix any appropriate
lines with something - usually a >. procmail does for sure. (In
theory, this should not be necessary as your mail has already been run
through a POP3 delivery and download... but if the server uses maildir
instead of mbox folders, it may not.)
Is that treated as a new message? I think not. I'm going to go look at
the fetchmail code, maybe I can make a patch for it to do this.
The cannonical separator for mbox mail folders is a line beginning with
"From " (note the space!). If you look for "\n\nFrom ", you'll miss the
first message because it won't have any preceding newlines. <g> Many
POP3 daemons actually read more of the line to make sure it looks
something like:
From [EMAIL PROTECTED] Sun Jan 1 00:00:02 2006
But some don't. :/ I got bitten by that briefly with a custom delivery
agent I wrote for the domain hosting system I'm administering.
-kgd
