fetchmail-users — User questions and discussion

[fetchmail-users] confused about system wide and private setups

[Bob M. <or...@gm...>]

Hi:

I'm using Debian Sarge with fetchmail version 6.2.5-12sarge4.

How may setup fetchmail to download mail at different intervals for some
users?

I didn't understand if I can mix system wide fetchmailrc with private or
personal .fetchmailrcs for _some_ users.

If I create .fetchmailrcs, which process runs it? Do I have to create cron
jobs for this users?

TIA for your help,

-
Robert

Re: [fetchmail-users] Running fetchmail as root for all users

[Rob M. <rob...@gm...>]

On 8/16/06, Michelle Konzack <lin...@fr...> wrote:
> "ssmtp" can deliver but not receive.  "ssmtp" is a MTA which pull
> only messages out opf the box and not more.  So this box can never
> be used as an Open-SMTP-Relay.
>
> All of my servers (over 80) are using ssmtp for security reason.

You don't need ssmtp for that.  Any SMTP server can be bound to
loopback only.  In the case of sendmail (8.12 and later) you can run
only the client daemon only (which only handles mail created locally).

However, for your fetchmail box you'll either need to add a true SMTP
server (even if only bound to loopback) or tell fetchmail to deliver
the mail directly to your real SMTP server.

-- 
                 Please keep list traffic on the list.

Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-users] Has anyone ever seen "Fetchmail saw more than N timouts while attempting to get mail from ..."

[Matthias A. <mat...@gm...>]

Michelle Konzack <lin...@fr...> writes:

>> I asked about 4.6.7 or newer, not 4.6.4...
>
> I know... but since I use Debian GNU/Linux (2.1, Slink) since 03/1999
> I was starting with fetchmail 4.6.4 and never have seen such messages...

Does that imply you have been using versions 4.6.7 to 6.3.4?

-- 
Matthias Andree

Re: [fetchmail-users] Running fetchmail as root for all users

[Michelle K. <lin...@fr...>]

Am 2006-08-11 18:58:13, schrieb Rob MacGregor:
> On 7/27/06, Michelle Konzack <lin...@fr...> wrote:
> >
> > And if there is no "real" MTA (we use ssmtp) ?  I have tried the setup
> > as user "fetchmail" and I can not deliver to the other around 180 users.
> 
> So, point fetchmail at SSMTP, or are you saying that the box that runs
> the POP accounts doesn't have any SMTP service that can deliver mail?

"ssmtp" can deliver but not receive.  "ssmtp" is a MTA which pull
only messages out opf the box and not more.  So this box can never
be used as an Open-SMTP-Relay.

All of my servers (over 80) are using ssmtp for security reason.

Greetings
    Michelle Konzack


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Re: [fetchmail-users] Has anyone ever seen "Fetchmail saw more than N timouts while attempting to get mail from ..."

[Michelle K. <lin...@fr...>]

Am 2006-08-12 12:39:27, schrieb Matthias Andree:
> Michelle Konzack <lin...@fr...> writes:
> 
> > Am 2006-07-15 15:28:46, schrieb Matthias Andree:
> >> Greetings!
> >
> > Greetings too
> >
> >> This message is supposed to be mailed to a user since 4.6.7, but the
> >> code I've looked at makes it rather unlikely (not to say impossible) to
> >> ever be mailed on operating systems that I'm used to. Before removing
> >> the relevant code for the 6.3.5 update, I'd like to know if someone is
> >> getting these messages.
> >
> > Hmmm, 4.6.4 was in Debian/Slink for 9 years... and since I use Debian
> 
> I asked about 4.6.7 or newer, not 4.6.4...

I know... but since I use Debian GNU/Linux (2.1, Slink) since 03/1999
I was starting with fetchmail 4.6.4 and never have seen such messages...

I mean on any of my Systems including different architectures like
i386, m68k, powerpc, sparc, mips and ia64.

Greetings
    Michelle Konzack


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

[fetchmail-users] fetchmail 6.3.5-beta2 snapshot

[Matthias A. <mat...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

I have uploaded a new fetchmail beta 6.3.5-beta2 snapshot to the usual
download location: <http://mandree.home.pages.de/fetchmail/>

Please test:

1. behavior after logged timeouts and report inconsistencies along with
   your operating system and version.

2. IMAP AUTH=EXTERNAL

Thank you.

Changes in fetchmail 6.3.5-beta2 since 6.3.5-beta1:

* Track getaddrinfo() results to properly free them after timeouts and make sure
  that getaddrinfo() isn't interrupted by a timeout (which breaks on MacOS X),
  reported by Uli Zappe.  This should fix Debian Bug#294547 and Bug#377135.
* fix compilation on systems that don't know struct addrinfo (Solaris 2.6).
* ignore SIGPIPE signals and rely on functions to return EPIPE instead. This is
  necessary because the former longjmp() from the signal handler is unsafe and
  makes the whole fetchmail behavior undefined after the event.
* switch setjmp/longjmp to sigsetjmp/siglongjmp
* IMAP now supports the EXTERNAL authentication method, courtesy of
  Götz 'nimrill' Babin-Ebell, BerliOS patch #1095 with minor changes.
* The sslproto keywords are now case insensitive, courtesy of
  Götz 'nimrill' Babin-Ebell, BerliOS patch #1095.

Happy fetching,
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFE4QorvmGDOQUufZURAndcAJwIImfpRb6u23Pqz3RZpxKEpCW0hACgy369
uS63EI3GT9eflaS80N8QmI0=
=Du1r
-----END PGP SIGNATURE-----

Re: [fetchmail-users] Getting Postfix to add header info for fetchmail

[Matthias A. <mat...@gm...>]

Dale Pontius schrieb:
> The problem is that my family receives mail through multidrop, she sends
> email to multiple family members, and her machine shares a domain name
> with my LAN. In addition, I have a forwarding domain at DynDNS.org that
> both she and my family use, and that name corresponds to the LAN names
> for all of our machines. Therefore here Postfix won't send email to my
> family, because it thinks the mail is local. I could set up an alias to
> send email directly to my ISP account, but then it appears that all
> multidrop information is lost.
> 
> So I think the question is: How do I get Postfix to add the right
> headers so that multidrop can figure out who gets a piece of mail?

The good thing is, if ALL received messages pass through the same Postfix
box, it's trivial, as any halfway recent Postfix version (2.2.X for sure)
will add, upon delivery (ok, this isn't 100% accurate), one Delivered-To:
and one X-Original-To: header. There are subtle differences in semantics WRT
forwarding and rewriting, but I'm confident one of these headers will suit
your needs.

See fetchmail's "envelope" configuration keyword to point it towards the
right header.

> I've done some command line experiments, and on the first "Received:"
> line, where Postfix gets the mail from the 'mail' command, there is no
> "for gra...@fa..." so there is no information for fetchmail to do
> multidrop.

Using Received: headers for multidrop is ill-advised, quite picky about
formatting (more documentation to show in 6.3.5's manual page), and I
wouldn't recommend doing that if you can help it.

> Maybe I'm asking the wrong question. Maybe rather than adding header
> information there's some way to tell Postfix that half of this domain is
> here, and half is over there. I'll be at her house in the next few
> weeks, and would like to try and fix this up locally. (While I'm busy
> bringing her up to date - she gets security updates only from 600+ miles
> away.)

Well, transport_maps (see: man 5 transport) may help you out, but you may
need to configure the complete domain with complementary routing information
(local vs. smtp) on both sides. This goes way beyond the topic of the list,
so may I suggest that you read up on the pointers I've given and then ask
the Postfix setup details on the postfix-users list?

Please join the fetchmail-users list at berlios.de, too. see
www.fetchmail.info for links.

Re: [fetchmail-users] Running fetchmail as root for all users

[Matthias A. <mat...@gm...>]

Michelle Konzack <lin...@fr...> writes:

> And if there is no "real" MTA (we use ssmtp) ?  I have tried the setup
> as user "fetchmail" and I can not deliver to the other around 180 users.

BTW, ssmtp is going away:
http://packages.qa.debian.org/s/ssmtp.html
http://bjorn.haxx.se/debian/testing.pl?package=ssmtp

-- 
Matthias Andree

Re: [fetchmail-users] Running fetchmail as root for all users

[Matthias A. <mat...@gm...>]

Michelle Konzack <lin...@fr...> writes:

> And if there is no "real" MTA (we use ssmtp) ?  I have tried the setup
> as user "fetchmail" and I can not deliver to the other around 180
> users.

You don't need ssmtp for fetchmail. Fetchmail talks SMTP.

-- 
Matthias Andree

Re: [fetchmail-users] reasonable poll intervals

[Matthias A. <mat...@gm...>]

Michelle Konzack <lin...@fr...> writes:

> Am 2006-07-12 08:05:43, schrieb Matthias Andree:
>
>> That's what IMAP's IDLE extension is for, with that, the client will be
>> notified of new messages without having to reconnect often.
>> Unfortunately, this works only well in 6.3.4 and only if fetchmail is
>> polling one account only.
>
> Oops...  A new feature?

Not new, but older IDLE implementations in fetchmail were somewhat buggy.

-- 
Matthias Andree

Re: [fetchmail-users] Has anyone ever seen "Fetchmail saw more than N timouts while attempting to get mail from ..."

[Matthias A. <mat...@gm...>]

Michelle Konzack <lin...@fr...> writes:

> Am 2006-07-15 15:28:46, schrieb Matthias Andree:
>> Greetings!
>
> Greetings too
>
>> This message is supposed to be mailed to a user since 4.6.7, but the
>> code I've looked at makes it rather unlikely (not to say impossible) to
>> ever be mailed on operating systems that I'm used to. Before removing
>> the relevant code for the 6.3.5 update, I'd like to know if someone is
>> getting these messages.
>
> Hmmm, 4.6.4 was in Debian/Slink for 9 years... and since I use Debian

I asked about 4.6.7 or newer, not 4.6.4...

-- 
Matthias Andree

Re: [fetchmail-users] Running fetchmail as root for all users

[Rob M. <rob...@gm...>]

On 7/27/06, Michelle Konzack <lin...@fr...> wrote:
>
> And if there is no "real" MTA (we use ssmtp) ?  I have tried the setup
> as user "fetchmail" and I can not deliver to the other around 180 users.

So, point fetchmail at SSMTP, or are you saying that the box that runs
the POP accounts doesn't have any SMTP service that can deliver mail?

-- 
                 Please keep list traffic on the list.

Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-users] Has anyone ever seen "Fetchmail saw more than N timouts while attempting to get mail from ..."

[Michelle K. <lin...@fr...>]

Am 2006-07-15 15:28:46, schrieb Matthias Andree:
> Greetings!

Greetings too

> This message is supposed to be mailed to a user since 4.6.7, but the
> code I've looked at makes it rather unlikely (not to say impossible) to
> ever be mailed on operating systems that I'm used to. Before removing
> the relevant code for the 6.3.5 update, I'd like to know if someone is
> getting these messages.

Hmmm, 4.6.4 was in Debian/Slink for 9 years... and since I use Debian
I have never seen such message, even if my ISP's mailserver was offline
or I had a line drop for some days and fetchmail had tried to poll the
servers severt 1000' times...

Greetings
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Re: [fetchmail-users] reasonable poll intervals (was: Re: Rotating the log file)

[Michelle K. <lin...@fr...>]

Am 2006-07-12 08:05:43, schrieb Matthias Andree:

> That's what IMAP's IDLE extension is for, with that, the client will be
> notified of new messages without having to reconnect often.
> Unfortunately, this works only well in 6.3.4 and only if fetchmail is
> polling one account only.

Oops...  A new feature?  This would mean, that I have 180
fetchmails running in the background, one for each user... 

Or do I mis something?

And I have more then 600 Mailboxes to poll...

Oh yes, since my ISP support IMAP (courier) I use expunge 1 to prevent
downloading of messages twice, if I have a line-drop on my 3.5 MBit SDSL.

Greetings
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Re: [fetchmail-users] reasonable poll intervals (was: Re: Rotating the log file)

[Michelle K. <lin...@fr...>]

Am 2006-07-12 00:37:51, schrieb Uli Zappe:
> Am 11.07.2006 um 11:37 schrieb Matthias Andree:
> 
> >checking new mail every 3 minutes [is] abusive
> 
> Oooops!?! How so? I use 30 seconds as poll interval. Admittedly, most  
> of the people I know that use fetchmail use something between 60 and  
> 120 seconds, but personally I don't know anyone who would use an  
> interval longer than 120 seconds.

Even if my ISP allow me to do it, <frrenet.de> is hosting arround
5 million mailboxes on around 90 Servers, which mean, 55.000
mailboxes per <mboxXX.freenet.de>.  If all peoples would use
such intervall, no server will handle this load...

Since I have over 600 Mailboxes to poll, located on around 40 mbox-
server I poll it only serial and then only all 10 minutes which is
enough.

Many of those mailboxes must be processed independatly from a MUA,
so changing a MUA to use IMAP over the internet does not work.

(I have my own local Courier running and ALL mails need preprocessing)


Greetings
    Michelle Konzack


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Re: [fetchmail-users] Rotating the log file

[Michelle K. <lin...@fr...>]

Am 2006-07-10 20:46:36, schrieb Stephen Allen:
> Rob MacGregor wrote:
> >Have you considered using syslog instead of logfile?
> 
> That would be a good idea if you could control more of what gets logged 
> there.  At the moment, my fetchmail daemon runs every 180 seconds and 
> checks email from half-a-dozen POP3 servers.  Most of it's log is filled 
> with:

Do not run it ad daemont but from your crontab with

   */3 * * * * <user> fetchmail --logfile /path/`date +%Y-%m-%d`.log

which will write dayly named logs

Greetings
    Michelle Konzack


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Re: [fetchmail-users] Running fetchmail as root for all users

[Michelle K. <lin...@fr...>]

Am 2006-07-06 08:20:49, schrieb Rob MacGregor:
> On 7/6/06, Stephen Allen <fet...@ro...> wrote:
> >The subject may be a little misleading... in my scenario we have 10 ISP
> >POP3 accounts that map to 8 local users.  The way I set it up a few
> >years ago was fetchmail running as root and collecting mail for all POP3
> >accounts.  I've since discovered that fetchmail is normally run on a
> >per-user basis.
> >
> >Given that the users never log in to a shell, what is the best
> >configuration in my case?  Are there pros/cons of doing it either way?
> 
> There is no need, unless you're passing email directly to a non-SUID
> MDA, to run fetchmail as root.  Indeed, future versions of fetchmail
> will refuse to run as root.  I haven't run fetchmail as root since
> before 6.0 was released and have not had any problems.
> 
> Simply run it as a standard user (say "fetchmail") and have it pass
> email to your MTA.

And if there is no "real" MTA (we use ssmtp) ?  I have tried the setup
as user "fetchmail" and I can not deliver to the other around 180 users.

Sorry for the late question, but I was some month not availlable and
came back from Palestine for 3 weeks (after 8 days prison illegal).

Greetings
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/6/61925193    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

[fetchmail-users] fetchmail 6.3.5-beta1 snapshot

[Matthias A. <mat...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

after a few not so easy fixes, I am providing a fetchmail snapshot,
dubbed fetchmail 6.3.5-beta1, for public preview.
Download location: <http://mandree.home.pages.de/fetchmail/>

Changes in fetchmail 6.3.5-beta1 (since 6.3.4 release):

# NEW DEPRECATION WARNINGS:
* The "envelope Received" option may be removed from a future release, because
  the Received header was never meant to be machine-readable, the format varies
  widely, and various other differences in behavior make parsing Received an
  unreliable undertaking. The enveloper option as such will remain though, in
  order to support Delivered-To, X-Envelope-To, X-Original-To and similar.
  See also <http://home.pages.de/~mandree/mail/multidrop>.
* Kerberos IV support may be removed from a future fetchmail release.
* SIGHUP wakeup may be removed from a future fetchmail release and cause it
  to terminate.
* Support for operating systems that are not sufficiently POSIX compliant may be
  removed or operation on such systems may be suboptimal for future releases.

# KNOWN BUGS AND LIMITATIONS:
+* fetchmail expects Received: headers in a particular format when parsing
+  envelopes.

# BUG FIXES:
* For protocols such as IMAP that are not delimited by "." lines, truncate the
  input buffer when the message has been completely read, to avoid taking
  trailing garbage into the message if the terminal CRLF is missing. Fixes
  Debian Bug#312415. (Patch suggested by Mike Jones, Manchester Univ.).
* When using NTLM authentication, use regular IMAP response code handler after
  completing NTLM handshake, for robustness and consistency.
  (Taken from the NetBSD portable packages collection, patch-ac.)
* Support Kerberos installations where krb5.h and perhaps roken.h are in
  .../include/krb5.  Taken from NetBSD portable packages collection patch-ae.
* On NetBSD, link against -lroken -lcom_err if --with-kerberos is enabled.
* Drop #include <com_err.h> from Kerberos 5 header file, fixes compile error on
  SUSE Linux 10.0.
* Fix des_pcbc_encrypt compile warnings in kerberos.c line 246.
* If krb5-config provides gssapi library information, use that rather than
  guessing.
* Improve --with-gssapi auto detection for /usr-based GSSAPI installs.
* Fix --with-gssapi builds for NetBSD 3.0.
* Improve KAME/getnameinfo.c portability to Linux libc5 systems.
  Based on a patch by Dan Fandrich.
* Provide INET6 to KAME/getnameinfo.c (only useful on IPv6-enabled systems that
  lack getnameinfo, and there only visible in some Received: headers).
  Found by Dan Fandrich.
* POP3: some UID flags may not be set properly on UIDL lists. (Sunil Shetye)
* Make IMAP4 IDLE work on servers that do not update RECENT counts.
  Reported by Lars Tewes.
* IMAP4 patch by Sunil Shetye:
  - do not depend on server updating RECENT counts at all
  - also enter IDLE loop when messages are present on the server.
* Fix --flush description in the manual page, fetchmail does not mark messages
  seen unless it has successfully delivered them. Suggested by Frederic Marchal.
* Fetchmail no longer attempts to stat the "-" file in daemon mode -- this is a
  special name to read the RC file from stdin, and cannot always be re-read
  anyways. BerliOS bug #7858.
* When looking up ports for a service, the lookup succeeds and the returned
  address family isn't IPv4 or IPv6, properly free the allocated memory from the
  service lookup. Found by Uli Zappe.
* When looking up ports for a service, only look up TCP ports.
* Avoid compiling empty files, to avoid diagnostics from strict compilers.
* If the lockfile ends before the process ID, treat it as stale and unlink it.
  Reported by Justin Pryzby, Debian Bug #376603.
* SIGHUP wake-up behavior was broken since 5.9.13's Cygwin changes, in that for
  non-root users, SIGHUP would abort the first poll and subsequently interfere
  with new polls, and SIGHUP would be ignored for root users. SIGHUP now matches
  documented behavior. SIGUSR1 has always been a wakeup signal for both root
  (undocumented) and non-root users. See also the deprecation warning above.
* When a connection fails, log not only the IP address, but also host and
  service name and the port number. Log the latter when trying to connect in
  verbose mode, too.
* Keep syslog output at one line per message (this works if no errors occur).
* Track getaddrinfo() results to properly free them after timeouts,
  reported by Uli Zappe.  This MIGHT fix Debian Bug#294547 and Bug#377135.
* Fetchmail in verbose mode now logs if it opportunistically upgrades a POP3
  or IMAP connection to TLS security with STLS/STARTTLS.
* --logfile is now handled more carefully, errors opening the logfile are
  now reported to the TTY where fetchmail was started from.
* fetchmail now complains and aborts when it cannot properly daemonize itself.
* fetchmail now supports fo...@ex...=bar user mappings for multidrop boxes.

# CHANGES:
* Rename all fetchmail-internal lock_* functions to fm_lock_*. Obsoletes
  NetBSD portable packages collection patch-ah, patch-ai and patch-aj.
* Configure prints a warning (but proceeds) if Kerberos IV support is enabled.
* In verbose mode, log every IP fetchmail tries to connect to, to avoid
  misleading the user. Suppress EAFNOSUPPORT errors from socket() call, too.
  Fixes Debian Bug #361825, reported by Daniel Baur.
* In idle mode, fetchmail complains about the fetchall option.

# CONTRIBUTED SCRIPTS:
* PopDel.py was revised by Joshua Crawford to display the From: address and
  list every email, even if it has no Subject: header; and not delete the wrong
  message in the presence of mail without Subject: headers.

Happy fetching,
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFE1zgvvmGDOQUufZURAkhgAJ4zllZl0gWjJ9kD6Um9I6uWXAoO2ACfS9I2
NZYdxTe1Gd5yZN0xpKn31mc=
=9bIu
-----END PGP SIGNATURE-----

Re: [fetchmail-users] Multi-drop problems

[Matthias A. <mat...@gm...>]

Matthias Andree <mat...@gm...> writes:

> Well, fetchmail doesn't support full addresses in user mappings yet,
> thus you'll need to rewrite your configuration a bit, hoping that
> (mypartner) is different from (username) and that
> (mypartner) is also different from (myname).

I have just implemented full-address mappings (as Andrew Longland-Meech
tried in his original configuration), to appear in the upcoming
fetchmail 6.3.5 version.

These full-address mappings will apply after qvirtual stripping and have
highest precedence, i. e. they are valid even if no localdomains, aka,
via or DNS alias matches are found.

-- 
Matthias Andree

Re: [fetchmail-users] Error 550 fetchmail-postfix-cyrus

[Matthias A. <mat...@gm...>]

Kwadwo Owusu schrieb am 2006-08-03:

>                        The Postfix program
> 
> <ro...@ox...> (expanded from
>    <pos...@lo...>): host
>    /var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp] said: 550-Mailbox
>    unknown.  Either there is no mailbox associated with this 550-name or you
>    do not have authorization to see it. 550 5.1.1 User unknown (in reply to
>    RCPT TO command)

It's hard to tell what exactly went wrong. Generally, you have two
options (I'm not sure if webmin supports one, the other, or both - in
doubt, check with SUSE - you've got their commercial product after all).

- map the postmaster to an existing user at your site with Postfix aliases,
  check the Postfix configuration and manual

- configure fetchmail to send root messages to the right user:
  set postmaster "user@domain.example" (put this before the first "poll"
  stanza)

HTH,

-- 
Matthias Andree

[fetchmail-users] Error 550 fetchmail-postfix-cyrus

[Kwadwo O. <kwa...@gm...>]

I have installed Open-xchange on SLES9 for a client. We have a DSL
connection to the Internet. Unfortunately the provider will not give
us a static public IP. We have a POP3 account with a mail hosting
provider that up till now the client has been using a web interface to
access mail for one user. The account has now been turned into a
catchall for the domain (Multidrop)

I have configured fetchmail (using webmin) to pull all mails destined
for the clients domain to the mail server running postfix and cyrus.
This works, but I get the error message 550 from postfix (actual
domain name changed to anydomain.com):

This is the Postfix program at host ox.anydomain.com.

I'm sorry to have to inform you that your message could not be
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                       The Postfix program

<ro...@ox...> (expanded from
   <pos...@lo...>): host
   /var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp] said: 550-Mailbox
   unknown.  Either there is no mailbox associated with this 550-name or you
   do not have authorization to see it. 550 5.1.1 User unknown (in reply to
   RCPT TO command)


Final-Recipient: rfc822; ro...@ox...
Original-Recipient: rfc822; pos...@lo...
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host
   /var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp] said: 550-Mailbox
   unknown.  Either there is no mailbox associated with this 550-name or you
   do not have authorization to see it. 550 5.1.1 User unknown (in reply to
   RCPT TO command)

Using open-xchange i created the accounts with simple first names for
the staff for example  paul, angela, etc.  and the email addresses as
fir...@do.... Only one person, the md, has his account as
p.mueller and his email address as p.m...@do...

The server's host and domain name was configured in ldap during the
sles9 installation.

In fetchmail I run a single fetchmailrc for all users, using the (*)
as a catchall for all local users.

Any help to rectify this problem would be much appreciated.


Kwadwo Owusu

Re: [fetchmail-users] Multidrop fetchmail bouncing non-existing local addresses

[Andy H. <adh...@gm...>]

Hi,

On 7/31/06, Matthias Andree <mat...@gm...> wrote:
> I'll take a look as my time permits.
>
> 8-)

That's all I can ask for :)

Andy

Re: [fetchmail-users] Multidrop fetchmail bouncing non-existing local addresses

[Matthias A. <mat...@gm...>]

"Andy Hawkins" <adh...@gm...> writes:

> Hi,
>
> On 7/28/06, Rob MacGregor <rob...@gm...> wrote:
>> You've probably missed the fact that these days Matthias pretty much
>> is the entire fetchmail development team (or at least all of it you'll
>> see on the lists, I think some of the others are still around, if not
>> terribly active).  This means that there isn't a lot of developer time
>> available, hence why you rarely see him on the lists.
>
> Not so much 'missed' as 'didn't know'.
>
> My 'hurry up' e-mail was in no way intended to show dissatisfaction in
> the responses I was receiving, more a reminder to people that I was
> still interested in an answer.
>
> A simple 'I'll take a look at it when I have time' was all I was looking for.

I'll take a look as my time permits.

8-)

-- 
Matthias Andree

Re: [fetchmail-users] Multidrop fetchmail bouncing non-existing local addresses

[Andy H. <adh...@gm...>]

Hi,

On 7/28/06, Rob MacGregor <rob...@gm...> wrote:
> You've probably missed the fact that these days Matthias pretty much
> is the entire fetchmail development team (or at least all of it you'll
> see on the lists, I think some of the others are still around, if not
> terribly active).  This means that there isn't a lot of developer time
> available, hence why you rarely see him on the lists.

Not so much 'missed' as 'didn't know'.

My 'hurry up' e-mail was in no way intended to show dissatisfaction in
the responses I was receiving, more a reminder to people that I was
still interested in an answer.

A simple 'I'll take a look at it when I have time' was all I was looking for.

Cheers

Andy

Re: [fetchmail-users] Simple fetch and forward

[Matthias A. <mat...@gm...>]

"John" <fet...@je...> writes:

> X-Original-To isn't always there. If I get a mail directed at a mailing list
> or sent as a bcc then it isn't always obvious what the sender was.

So it's not your upstream writing that header?

> When the message hits procmail, I run a little script and this
> extracts a likely original destination address, irrespective if it was
> sent Bcc or via a list,

This works in good weather, and fails in bad unfortunately.

> I was originally trying to use Fetchmail's multidrop mode to do what I
> wanted but I didn't fully understand the anatomy of an email so I read
> the RFC and re-thought what I was doing. I don't know if I am doing
> this the best way, but what I've got works for me - it's just a
> prototype but it seems to be ok.

The best is if your POP3 or IMAP service provider adds some reliable
header, be it Delivered-To:, X-Original-To:, X-Envelope-To: or
similar. If they don't, ask them if they can do that.

<http://home.pages.de/~mandree/mail/multidrop> sums up requirements for
multidrop in a way that is a tad less technical than a RFC.

-- 
Matthias Andree