Story Of An Email

Home » CentOS » Story Of An Email
CentOS 13 Comments

I’m running postfix + dovecot on my CentOS server, together with amavisd, clamd and spamassassin, following the instructions in
. As far as I can see it is all working, but I must admit I’m not clear exactly what path an incoming email travels along. I asked this question before, and someone suggested a document I should read, but unfortunately I’ve mislaid the note I made at the time.

So if someone could enlighten me –
or point to a source of enlightenment –
I should be most grateful.

13 thoughts on - Story Of An Email

  • Patrick Lists wrote:

    I’m afraid this document only tells me about one small step on the journey. It doesn’t mention amavis, fetchmail or dovecot. I run fetchmail (through cron.d) to collect email from various email servers. So the first step, I guess, is that fetchmail passes the email through port 25 to the postfix sendmail emulator?

  • If you completed the steps in that article, then fetchmail would be grabbing the mail from the Dovecot server.

    Really short version.

    Mail sent to your machine, on port 25, would go to postfix, which would then do something with it.

    Where is fetchmail pulling? From your Dovecot server?
    If so, then mail comes in, goes to postfix, which sends it to Dovecot, where you then get it from fetchmail.

    Slightly longer version.

    Mail on port 25 comes into your server, e.g., postfix, which would then, again, assuming you made a setup like Ned’s article, give it to Dovecot.

    As an example, my even simpler setup has mail coming into my postfix server, which I then set up to pass along to maildrop to filter and deliver the mail. For a pop account from my ISP, for example, the that I use on this list, I have getmail (same idea as fetchmail) pull it, and it makes no use of my postfix server.

    If fetchmail is pulling from your ISP, or gmail, then that wouldn’t be working with postfix, it would be something between you and gmail or ISP.

    I haven’t followed the thread, so am not entirely sure I’ve answered your question.

  • Timothy,

    Assuming that you’ve properly configured the and to allow amavisd/clamav scanning of email, the following is how the process will flow:

    Remote mail client (user, some other mail server, etc) connects to port 25
    to send an email through your Postfix installation.

    Postfix passes the email to amavisd over some port.

    Amavisd processes the email through clamav and, if the message is clean, passes it back to Postfix through a different port.

    Postfix delivers the message (to a remote mail server, or to a local user).

  • Mike Burger wrote:

    Thanks for your response. I’ve a couple of queries.

    1) Where does SpamAssassin come into the process?

    2) In my case all incoming email comes through fetchmail from external mail servers like gmail. I take it that this is sent through port 25 to postfix, more precisely to the sendmail emulator of postfix?

    3) I take it that in the last stage postfix passes the email to dovecot, which stores it in ~/Maildir/cur/ (in my case).

    It is picked up from there by KMail on my laptop, but that is another story.

  • postfix, exim and many others applications are merely servers that respond to and process emails according to the SMTP protocols. There’s nothing special about sendmail except that it was one of the first and most widespread of mail servers.



  • Traditional unix programs expect to be able to pipe through an executable named sendmail when they want to send mail. Postfix provides such an executable. I don’t know offhand if fetchmail pipes through sendmail for local delivery or uses SMTP protocol, but if it runs an executable named sendmail that is not actually sendmail, it seems reasonable to call that emulation. Actually it seems reasonable either way to me, but I suppose that’s a matter of opinion…

  • Fetchmail (and getmail) don’t make use of SMTP. As their name suggests, they get mail, pulling it from a pop or imap server, whether on your ISP or local server. From there, they might send it elsewhere, depending upon the setup.

    I’m not sure about fetchmail, but getmail, for example, will hand my emails off to maildrop, which then sends them through spamc before going further.
    In contrast postfix, which I use for a barely used account, will also get my mail, and in my case, again hand it off to maildrop.

    So while one could have fetchmail or getmail hand off to postfix it seems to me that the more common scenario would be having them hand off to procmail, maildrop, or something similar.

  • Yes it does.

    As each message is retrieved, fetchmail normally delivers it via SMTP
    to port 25 on the machine it is running on (localhost), just as though
    it were being passed in over a normal TCP/IP link. fetchmail provides
    the SMTP server with an envelope recipient derived in the manner

    So, for example, in my fetchmailrc file:
    poll verizon via port 995
    user verizonusername is foo here

    If I look at the headers of a message:

    Received: from (localhost [])
    by (8.13.8/8.13.8) with ESMTP id p6LKB3b6010977
    for ; Fri, 29 Nov 2013 16:11:03 -0400

    It’s clear this was passed from fetchmail to the local SMTP server.

    Of course you _can_ configure fetchmail to operate differently, but this is its default behaviour.

  • Well thank you. I actually had the correct thought in my head and typed the wrong word, meaning the write postfix rather than SMTP. Although having used getmail for many years, I hadn’t realized that fetchmail does use SMTP to deliver, so I stand corrected both in fact and intention.

    Getmail can reinject through SMTP if necessary too, so even the intention was incorrect. I blame it on the lack of caffeine, which I shall now rectify. :)

  • 1) Usually via procmail, called in /etc/procmailrc. On my system, that file contains:


    :0 fw
    | spamc

    :0 e

    2) Fetchmail is, effectively, a mail client, and connects to Gmail via IMAP or POP3. Without seeing the fetchmail configuration (I’ve never had to make use of it), I’ll have to assume that fetchmail does pass the mail through to Postfix over port 25.

    To clarify on the second part of this question, there’s no “sendmail emulator” in play, though…Postfix is a replacement for Sendmail, with all the requisite functionality built in without having to resort to some sort of emulation.

    3) Postfix makes use of the procmail agent to deliver the email to the mail spools in /var/spool/mail and/or, if the user has procmail recipes in place to do any type of sorting/archival, mail spool files usually in
    $HOMEDIR/mail. Dovecot then queries those mailstores (POP3 will only query the inbox in /var/spool/mail, IMAP will query all of the other folders as long as your mail client requests it to do so).