<cfpop>

The previous lesson covered cfimap for reading mail over IMAP. cfpop covers the same basic capability over POP3, an older, simpler protocol, and its action list reflects that: no folder management at all, because POP3 itself has no concept of server-side folders the way IMAP does.

Learning Objectives

After completing this lesson, you'll be able to:

Retrieve message headers or full messages from a POP3 server with cfpop.
Delete and mark messages as read.
Explain why cfpop has far fewer actions than cfimap.

How cfpop Fits In

action="getHeaderOnly" / "getAll"

POP3 Server Contacted

Query Result Returned

delete Once Processed

A Basic Header Fetch

Tag Syntax

<cfpop
    server="pop.example.com"
    username="me@example.com"
    password="#popPassword#"
    secure="true"
    action="getHeaderOnly"
    name="messages"
    maxRows="25">

cfpop's Attributes

Attribute	Meaning
server	POP server hostname or IP (required)
username / password	Credentials for the mailbox
port / secure	Connection port and whether to use SSL (default false)
action	The operation to perform
name	Query result variable name
messageNumber / uid	Targets specific message(s) instead of the whole mailbox
attachmentPath	Required with getAll if attachments should actually be saved
generateUniqueFileNames	Avoids one message's attachment overwriting another's (default false)
startRow / maxRows	Pagination over the mailbox
timeout	Seconds to wait for the operation

cfpop's Four Actions

action	Does
getHeaderOnly	Returns message headers only
getAll	Returns headers, body text, and attachments (with attachmentPath set)
delete	Removes messages from the server
markRead	Marks messages as read

NOTE

That's the entire list, no createFolder, moveMail, or listAllFolders. POP3 itself has no concept of server-side folders, there's simply nothing for those actions to operate on.

A Real Example: Fetching, Then Deleting Once Processed

Tag Syntax

<cfpop
    server="pop.example.com"
    username="me@example.com"
    password="#popPassword#"
    action="getAll"
    name="incoming"
    attachmentPath="#expandPath('./received-attachments/')#"
    generateUniqueFileNames="true"
    maxRows="10">

<cfloop query="incoming">
    <cfset processIncomingMessage(subject, from, body)>
</cfloop>

<cfpop
    server="pop.example.com"
    username="me@example.com"
    password="#popPassword#"
    action="delete"
    uid="#valueList(incoming.uid)#">

NOTE

A typical POP3 workflow processes a batch, then deletes it explicitly. Without that delete step, the same messages get pulled again on the next poll, POP3 doesn't automatically track what's already been read the way IMAP's flags do.

A Real Engine Difference: Lucee's connection Attribute

Lucee's cfpop documents a connection attribute, hinting at persistent-connection reuse similar to cfimap and cfftp. Adobe's cfpop doesn't document any such attribute, or open/close actions at all, every call connects fresh. Both engines require Lucee's separate Mail Extension since Lucee 7.1 (the same requirement covered for cfmail and cfimap), and Lucee documents an explicit default port of 110.

Common Beginner Mistakes

Expecting cfpop to support folders like cfimap does

It can't, POP3 itself has no server-side folder concept. Use cfimap instead when folder organization or leaving mail on the server matters.

Forgetting to delete processed messages

Without an explicit delete, the same messages get retrieved again on the next poll, POP3 doesn't track read/unread state across separate connections the way IMAP does.

Calling getAll without attachmentPath, expecting attachments to be saved

Same as cfimap, attachmentPath is required for getAll if attachments should actually be written to disk.

Best Practices

Delete or explicitly track processed message UIDs to avoid reprocessing the same mail on the next poll.
Reach for cfimap instead of cfpop when folder organization, or leaving mail on the server after reading, is actually needed.
Use generateUniqueFileNames when saving attachments from more than one message in the same batch.

Interview Questions

Why does cfpop have far fewer actions than cfimap?

POP3 itself has no concept of server-side folders, so there's nothing for actions like createFolder or moveMail to operate on. cfpop only supports getHeaderOnly, getAll, delete, and markRead.

Why would the same email get processed twice by a cfpop-based script?

If it isn't explicitly deleted (or tracked) after processing, the next poll retrieves it again, POP3 doesn't track read state across connections the way IMAP's flags do.

What's required for cfpop to actually save a message's attachments?

attachmentPath must be set on a getAll call, the same requirement as cfimap.

Summary

In this lesson, you retrieved headers and full messages over POP3 with cfpop, deleted processed messages to avoid reprocessing them, and covered why cfpop's action list is so much smaller than cfimap's, POP3 itself has no server-side folder concept at all.

What's Next?

The next lesson moves into PDF generation, starting with an overview before the cfpdf, cfdocument, cfchart, and cfimage tags.