R. Berger:
> -The biggest problem now is that some clients can't get their email 
> using their exchange 2008 pop connector, because it stop after 5 
> messages with corrupt headers. I don't know where this comes from or to 
> find a solution.  This is a sample header:

I suggest that this is a question for the Dovecot mailing list.

> second problem is that on the first server (spamsnake) I get sometimes this 
> error:
> 
> Jan  7 14:56:56 bsd5 postfix/error[7639]: 0BF47A41459: 
> to=<[email protected]>, relay=none, delay=20, delays=20/0/0/0.01, 
> dsn=4.3.0, status=deferred (unknown mail transport error)

Look for an error/fatal/panic record BEFORE these.

http://www.postfix.org/DEBUG_README.html#logging

Look for obvious signs of trouble

Postfix logs all failed and successful deliveries to a logfile. The
file is usually called /var/log/maillog or /var/log/mail; the exact
pathname is defined in the /etc/syslog.conf file.

When Postfix does not receive or deliver mail, the first order of
business is to look for errors that prevent Postfix from working
properly:

    % egrep '(warning|error|fatal|panic):' /some/log/file | more

Note: the most important message is near the BEGINNING of the output.
Error messages that come later are less useful.

The nature of each problem is indicated as follows:

  * "panic" indicates a problem in the software itself that only a
    programmer can fix. Postfix cannot proceed until this is fixed.

  * "fatal" is the result of missing files, incorrect permissions,
    incorrect configuration file settings that you can fix. Postfix
    cannot proceed until this is fixed.

  * "error" reports an error condition. For safety reasons, a Postfix
    process will terminate when more than 13 of these happen.

  * "warning" indicates a non-fatal error. These are problems that
    you may not be able to fix (such as a broken DNS server elsewhere
    on the network) but may also indicate local configuration errors
    that could become a problem later.

> Third problem is that I have reject_unverified_recipient enabled but it 
> is not working I have one domain which receives about 100 mails an hour 
> off which 99 are spam. the use only one emailaccount (no catchall) but 
> the mail is refused at the second server after it has gone through the 
> spamsnake. This was working ok, but I don't know what I did to break 
> this ;-)

Unfortunately, there is not enough concrete content that allows
anyone to reproduce this.

        Wietse

Reply via email to