[Spambayes] strange statement that sb_imapfilter.py is not a proxyserver.

Tony Meyer tameyer at ihug.co.nz
Tue Aug 10 01:56:19 CEST 2004


> The above statements are very strange. If you telnet to port 
> 143 on a linux machine you are not talking to the mail server 
> (which is on port 25) but you are talking to the imap server.

There are many things which come under the umbrella term "mail server".  A
POP3 server is certainly a mail server, and typically lives on port 110 (or
955).  An IMAP4 server is certainly a mail server, and typically lives on
port 143 (or 993).  An SMTP server is certainly a mail server, and typically
lives on port 25.

> There is absolutely no configuration on a linux imap server
> as to what folders to access.

There is configuration as to which folders to *offer* (there has to be -
otherwise how would it know where the mail is?).  The output from the list
command indicated that the (IMAP4) mail server was offering thousands of
folders which it should not have been.  Almost certainly this configuration
will include a username variable in some way (e.g. it will be '~/Mail' or
'/Mail/{username}'), so that each user has a separate store.

> Information on which folders to access come from 
> the mail client on the local client machine. Which I thought 
> was the purpose of the configuration lines in the home 
> directory on the client under SpamBayes.

Yes, this is correct.  The output of the list command is which folders are
available to access, though, and that is under the control of the (IMAP4)
server.

> Since you confirm that sb_imapfilter.py talks to port 143 
> (that of imap) on the mail server it seems to me that 
> sb_imapfilter.py is a proxy server just as sb_server.py is.

No, not at all.

What happens with sb_server is that a mail client (e.g. Eudora) connects to
sb_server and sb_server connects to the (POP3) mail server and pretends that
it *is* the mail server (and transforms certain data that is sent to/from
the mail client).  It is proxying - acting as if it is someone else.

What happens with sb_imapfilter is that it (without any mail client)
connects directly to the (IMAP4) mail server and executes various IMAP4
commands (retrieving messages and storing new ones mostly).  Your mail
client cannot connect to sb_imapfilter - you were right in your earlier
message when you said that sb_imapfilter is a mail client itself.

If there was a SpamBayes IMAP4 proxy, then what would happen is that your
mail client would connect to (eg) sb_imap4proxy and sb_imap4proxy would
connect to the (IMAP4) mail server and pretend that it *was* the mail
server.  It would transform data sent to/from the mail client.

> Did I understand you to say that after sb_imapfilter.py 
> filters the mail on the server then the mail is brought down 
> to the client. How is that done?  Or did I misunderstand you?

The client (e.g. Eudora) does this (completely independently of anything
that sb_imapfilter does).  You tell the client "I want to view this
message", and the client asks the (IMAP4) mail server to fetch that message.
It's downloaded and displayed for the user.  (Often the client will then
cache the message, but that's not strictly necessary).

=Tony Meyer



More information about the Spambayes mailing list