Sorry, didn't notice this mail until now. It got sent to a bin
marked for mails that are replies, but that don't say what they're in
reply *to*, hence that cause aggravating issues with mail threading
if they end up in the standard mailbox. No biggie, just doesn't get
checked as often.
On Wed, Jul 19, 2006 at 12:07:09PM -0400, mlist [ at ] safenet-inc [ dot ] com wrote:
> Does Postfix have any place in the incoming mail path?
It does when you use "fetchmail".
Mail delivery is a complicated process. Maybe you're writing to a
single file (typically /var/mail/$USER). Maybe you're writing to a
Maildir-style mailbox directory. Maybe you're using an external mail
database service like Cyrus. Maybe you want procmail, maybe you
don't. Maybe you want to forward to some other server, or maybe you
want to just throw mail out or bounce it on the spot.
fetchmail doesn't try to be a Swiss army knife of mail delivery
systems -- MTAs already do that. Instead, it lets you configure
your mail server however you want, and then just transfer mail
between servers.
As I recall, fetchmail was also born in a time when most of its users
would either be casual users on Unix mainframes (hence already having
an MTA set up properly), or Linux enthusiasts on home PCs (hence
having an MTA and presumably not minding a little work to set it up).
According to Wikipedia, "Getmail" is a replacement to "fetchmail" that
allows direct delivery to files without going through an MTA. You may
want to look into that if you don't need MTA functionality. I don't
know whether or not it supports Cyrus, which I gather you're trying to
use (from the message I replied to earlier).
> Or should it be basically:
> - fetchmail to /Maildir for IMAP server
> or
> - fetchmail to ~/Inbox for direct local use by KMail
To my knowledge, fetchmail does not support direct delivery
without an MTA.
> If one is not filtering spam or the like, is there a need for (say)
> Procmail in the middle?
No.
> If KMail could accept mail from the ISP's POP3 server, and do its
> own sorting afterward, does it need anything different when
> fetchmail is used to get the mail from the ISP first?
Not to my knowledge. Note that . . .
* if your mail client has POP3 support,
* if you don't want procmail, or if your mail client supports
using procmail,
* if you don't want to sort things into multiple mailboxes, or if
your mail client supports that,
* if you don't want to get your mail from other mail programs,
* and if you don't want to store your mail in a special system
like an IMAP server, or if your mail client can POP mail and
store it to an IMAP server,
. . . then you may as well just use your mail client's POP3 capability
over fetchmail.
Sure, it's a long list, but the average user checking e-mail on their
home PC probably uses a single mail client with POP3, sorting, and
filtering, and doesn't need procmail or an IMAP server. I.e. all of
the above.
> If fetchmail is now the entity (instead of the mail reader such as
> KMail) that's going out to the ISPs POP server,
[...and if you're using an IMAP server, etc...]
> then the mail should just be dumped into <somewhere>/Maildir and the
> IMAP server worries about sorting it out and showing _copies_ to
> requesters that connect to (I forget the number of ) the IMAP
> service port, right?
Depends on the server. Cyrus cannot do this; you must deliver
your mail directly to Cyrus, which stores it in an efficient back-
end database.
I've never used any other IMAP server, but I *think* I remember
hearing that UW-IMAP uses Maildir-style mailboxes -- which some or
most MTAs support, and which I think procmail supports in case your
MTA doesn't.
I also think I remember that Courier can use standard "mbox" files,
i.e. the kind that you find in /var/mail/$USER by default.
I could have Courier and UW-IMAP reversed, though.
> My assumption was that the basic
[...]
> directories would be augmented by instructions from the connecting
> mail-reader, to create the useful category directories
Correct. IMAP-aware e-mail clients should allow you to create
mailboxes on the server. Mailbox creation requests are sent to the
IMAP server over the same connection you use to get your mail, and the
IMAP server does the actual work.
> and move received mail into them.
Not sure. Depends on the client, if any clients actually do this.
Personally, I've never seen this done, but I have seen disk-based mail
clients that download everything into one folder and then sort it from
there, so I suppose it's posssible that some do the same with IMAP.
Generally, though, I expect this sort of thing is generally done by
procmail, or in the case of Cyrus, by the "sieve" e-mail filtering and
filing language.
> > If not, it will go through the recipient list. Every recipient's
> > domain is looked up, using a DNS query for "MX" (Mail eXchange)
> > records. These denote mail servers set up to handle mail for that
> > domain. It connects to each of these (port 25) and sends the
> > envelope sender, the list of recipients that "reside" on that
> > server, and the headers and body.
>
> If one does not even have an in-house DNS server (little four-
> computer household LAN served by a LinkSys router and ADSL modem),
> is any of that last paragraph applicable?
Yes. The only way to deliver mail across the Internet is to either
send it directly to the appropriate site (using "MX" queries), or to
send it to a (configured!) SMTP relay. That relay in turn must either
go direct (MX), or give it to another relay.
But somewhere down the line, unless you happen to be sending e-mail
within your own organisation and you hit a relay that says, "hey, this
is for me!" (or for another host within the organisation), then you
will have to do the "MX" lookup. And if your mail server isn't
configured to use a relay, you *must* do the "MX" lookup.
Basically, for SMTP, the location (physical or virtual) of the DNS
server is irrelevant.
> Also, assuming that one intends to let the local ISP do everything
> outgoing, what (in say Postfix configuration) tells it to handle
> outgoing mail that way, rather than using the MX records to find a
> selection of remote servers directly?
In Postfix, the "relayhost" parameter. You set this to the name or IP
of an SMTP server that is configured to allow you to relay via it.
In the case of an ISP, they generally allow anyone in their IP block
to relay via their SMTP server.
> To put that question in more practical terms (or to highlight that
> I've misunderstood the concept...), what setting might a
> know-nuthin' have innocently answered/changed, not knowing that this
> causes Postfix to ignore the smarthost option.
I believe "smarthost" is the sendmail term, not Postfix. I'm not
aware of any options that would make Postfix ignore the "relayhost"
parameter. If they exist, I doubt you'd stumble on them accidentally.
> Or yet another way... if the complete configuration necessary to use
> DNS, MX records and selected remote servers is not in place, does
> Postfix default to looking at the ISP as a prospective smarthost?
No. There's no reliable way to determine this automatically. Plus
Postfix operates in a "do what I tell you" manner, not a "do what I
might possible want" manner -- unless your specific Linux distribution
tried to guess the appropriate configuration parameters, which seems
both unlikely and inadvisable.
> Is it likely that the know-nuthin' has put Postfix in a condition
> wher it isn't taking either option?
Doubtful. But check /var/log/mail* to see what it's doing with your
mail. It should give you plenty of information.
[...]
> I'd already told fetchmail to --keep (on the ISP) until I have
> things working locally, this resulted in a complete new download
> every ten minutes and 1.5 million files in my /Maildir,
To my knowledge, even if you keep things on your mail server, they're
still marked as "read" (as in "red") or "seen" once you've downloaded
them once. Unless you're using fetchmail with "--all", it should be
skipping over those items on the next pass.
If not, it suggests either your POP server is using broken software,
or "fetchmail" thinks it's not delivering the messages successfully
(even though it is, from your description).
Attachment:
signature.asc
Description: Digital signature