postfix, fetchmail and RSET
Hi all, Have server running postfix, maildir/ format, courier-imap to serve the clients, amavis for scanning virusses and spam, and fetchmail to get all mail from a dropbox at the isp. Fetchmail is running as root, .fetchmailrc: set postmaster "info" set no bouncemail poll mail.myisp.nl protocol POP3 localdomains mydomain.nl, localhost user "xxx" pass "xxxxxxx" to user * here options fetchall What I want is all mail, that has a to:address to an unknown local user is dropped in the local info box. Postfix main.rc (relevant lines): local_recipients_map = luser_relay = info@mydomain.nl I suspect I am wrong here: as I can interprete the logs, postfix gives a RSET to fetchmail, which causes fetchmail to stop immediately, not flushing the already read messages on the mailserver of the isp. Also, the message that goes wrong is not read, and not dropped in the general info-box. What do I have to change? TIA L1
The Monday 2004-02-02 at 22:19 +0100, Leen de Braal wrote:
user "xxx" pass "xxxxxxx" to user * here options fetchall
Is "*" an asterisk, or a placeholder for purpose of this email only? You need a real local user name there.
I suspect I am wrong here: as I can interprete the logs, postfix gives a RSET to fetchmail, which causes fetchmail to stop immediately, not flushing
call fetchmail with the -v option (verbose).
the already read messages on the mailserver of the isp.
That's because of fetchall. -- Cheers, Carlos Robinson
At 02:29 3-2-2004 +0100, Carlos E. R. wrote:
The Monday 2004-02-02 at 22:19 +0100, Leen de Braal wrote:
user "xxx" pass "xxxxxxx" to user * here options fetchall
Is "*" an asterisk, or a placeholder for purpose of this email only? You need a real local user name there.
This is an asterisk. Fetchmail always tries to find a name in a mail, that matches a local user. It has always worked for me. As far as I understood, if mail is not matching a local user, then it is delivered to postmaster?
I suspect I am wrong here: as I can interprete the logs, postfix gives a RSET to fetchmail, which causes fetchmail to stop immediately, not flushing
call fetchmail with the -v option (verbose).
I did, and here I found, that the reason is unknown user.
the already read messages on the mailserver of the isp.
That's because of fetchall.
Fetchall fetches also mails if status is read. This I added, because we had to use the webmailservice of the isp to check messages. If I don't use this, these messages on the isp-server are not transferred to the local mailserver, because the are already read. Messages are only flushed by fetchmail at the isp's pop3 server, if there is a positive signal, that mail is delivered locally. I think this (the RSET signal) is why they are not flushed. So this still leaves me with the question: How do i deliver messages in a local (maybe call it trash or spam) mailbox for users that are not known locally?
-- Cheers, Carlos Robinson
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
The Tuesday 2004-02-03 at 09:34 +0100, Leen de Braal wrote:
user "xxx" pass "xxxxxxx" to user * here options fetchall
Is "*" an asterisk, or a placeholder for purpose of this email only? You need a real local user name there.
This is an asterisk. Fetchmail always tries to find a name in a mail, that matches a local user. It has always worked for me. As far as I understood, if mail is not matching a local user, then it is delivered to postmaster?
Ah, I understand, a multidrop. I copy from the man page: | Here's an example of another kind of multidrop connection: | | poll pop.provider.net localdomains loonytoons.org toons.org: | user maildrop with pass secret1 to * here | | This also says that the mailbox of account `maildrop' on | the server is a multi-drop box. It tells fetchmail that | any address in the loonytoons.org or toons.org domains | (including subdomain addresses like `joe@daffy.loony | toons.org') should be passed through to the local SMTP | listener without modification. Be careful of mail loops | if you do this! I understand that with the asterisk it is postfix who is responsible of knowing to whom should each email be delivered, not fetchmail.
I suspect I am wrong here: as I can interprete the logs, postfix gives a RSET to fetchmail, which causes fetchmail to stop immediately, not flushing
call fetchmail with the -v option (verbose).
I did, and here I found, that the reason is unknown user.
Aha. So, postfix rejects that email. What should happen is that only that
email should be rejected, not all. Look at this sequence from my logs:
|Jan 30 10:32:51 nimrodel fetchmail[4908]: SMTP> RCPT TO:
the already read messages on the mailserver of the isp.
That's because of fetchall.
Fetchall fetches also mails if status is read. This I added, because we had to use the webmailservice of the isp to check messages. If I don't use this, these messages on the isp-server are not transferred to the local mailserver, because the are already read. Messages are only flushed by fetchmail at the isp's pop3 server, if there is a positive signal, that mail is delivered locally. I think this (the RSET signal) is why they are not flushed.
Yes, mail is actually deleted on "QUIT", not before. Also, not all servers mark mail as read, so fetchall will force getting all of them, again.
So this still leaves me with the question: How do i deliver messages in a local (maybe call it trash or spam) mailbox for users that are not known locally?
Reading the postfix faq, I see: |To disable the local_recipient_maps feature, specify: | | /etc/postfix/main.cf: | local_recipient_maps = | |With this setting, the Postfix SMTP server will not reject mail for |unknown local recipients. But I think you already did that:
Postfix main.rc (relevant lines): local_recipients_map = luser_relay = info@mydomain.nl
I suppose that you can send mail locally to "info@mydomain.nl", no? Test it. Otherwise, have a look at "usr/share/doc/packages/postfix/html/rewrite.html#luser_relay", I'm out of ideas. Paste a bit of your log, with real addresses modified. I can only offer to have a look at it :-) -- Cheers, Carlos Robinson
At 02:29 4-2-2004 +0100, Carlos E. R. wrote:
The Tuesday 2004-02-03 at 09:34 +0100, Leen de Braal wrote:
[...]
So this still leaves me with the question: How do i deliver messages in a local (maybe call it trash or spam) mailbox for users that are not known locally?
Reading the postfix faq, I see:
|To disable the local_recipient_maps feature, specify: | | /etc/postfix/main.cf: | local_recipient_maps = | |With this setting, the Postfix SMTP server will not reject mail for |unknown local recipients.
But I think you already did that:
Postfix main.rc (relevant lines): local_recipients_map = luser_relay = info@mydomain.nl
I suppose that you can send mail locally to "info@mydomain.nl", no? Test it. Otherwise, have a look at "usr/share/doc/packages/postfix/html/rewrite.html#luser_relay", I'm out of ideas. Paste a bit of your log, with real addresses modified. I can only offer to have a look at it :-)
Here goes something wrong in fetchmail trying to get the second message
from the ISP after a RSET because of unknown user:
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:
-- Cheers, Carlos Robinson
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
The Wednesday 2004-02-04 at 09:56 +0100, Leen de Braal wrote:
I suppose that you can send mail locally to "info@mydomain.nl", no? Test it. Otherwise, have a look at "usr/share/doc/packages/postfix/html/rewrite.html#luser_relay", I'm out of ideas. Paste a bit of your log, with real addresses modified. I can only offer to have a look at it :-)
Here goes something wrong in fetchmail trying to get the second message from the ISP after a RSET because of unknown user:
fetchmail: forwarding to localhost fetchmail: SMTP> MAIL FROM:
SIZE=957 fetchmail: SMTP< 250 Ok fetchmail: SMTP> RCPT TO: fetchmail: SMTP< 450 : User unknown in local recipient table fetchmail: SMTP error: 450 : User unknown in local recipient table fetchmail: SMTP> RSET fetchmail: SMTP< 250 Ok fetchmail: message dropbox@myisp.nl:1 was not the expected length (837 actual != 957 expected) not flushed
Ah. I think the mail server is broken and implements RSET badly. Perhaps it ignores it and continues reading.
fetchmail: POP3> RETR 2 fetchmail: POP3< Test for known user (ldb) fetchmail: POP3> QUIT fetchmail: POP3< fetchmail: client/server protocol error while fetching from mail.myisp.nl fetchmail: 6.2.3 querying mail.myisp.nl (protocol POP3) at Wed Feb 4 09:42:06 2004: poll completed fetchmail: Query status=4 (PROTOCOL) fetchmail: Writing fetchids file. fetchmail: normal termination, status 4 fetchmail: Writing fetchids file.
So here is a reason why the subsequent messages are not fetched: messagesize of first message is changed because of rewritten headers, and fetchmail looses track of the mails in the multidropbox in myisp.nl. How to avoid this??
I don't see how. You could send that query to the fetchmail developers or mail list, to see what can be done. Before that, read the docs to see if there is someway not to send RSET, but simply read the email through, but ignoring it. You can do something, perhaps: call fetchmail in daemon mode, so that instead of exiting it tries again after the predefined interval. If you are lucky, that mail will be marked "seen" already and ignored. Another idea: some servers support IMAP, even if they don't say they do: try. Just change the POP3 with AUTO in the config file. Imap supports much more cleanly skipping mails. One more, depending on the server - see this from fetchmail docs: | All these alternatives work in basically the same way | (communicating with standard server daemons to fetch mail | already delivered to a mailbox on the server) except ETRN | and ODMR. The ETRN mode allows you to ask a compliant | ESMTP server (such as BSD sendmail at release 8.8.0 or | higher) to immediately open a sender-SMTP connection to | your client machine and begin forwarding any items | addressed to your client machine in the server's queue of | undelivered mail. The ODMR mode requires an ODMR-capable | server and works similarly to ETRN, except that it does | not require the client machine to have a static DNS. That would be nice, but I have never seen it.
Second: postfix still refuses mail for unknown users.
Yes, that's the most important thing.
linux:/home/ldb # less /etc/postfix/main.cf | grep -v ^#:
Command "postconf" is more direct :-) And also more exact, it is the actual configuration as seen by postfix.
mail_spool_directory = /var/mail canonical_maps = hash:/etc/postfix/canonical
I think it is correct, first glance...
I have tried to remove reject_unauth_destination in this line:
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
but this gives me a postfix-throttle. I will dig into the docs about rewrite#luser_relay. I am still missing something.
Test sending an email locally to "info@mydomain.nl", and if it works, repeat from an external account. If that account is unreachable, it would explain why it is failing. In that case, save your configuration, and start afresh, letting Yast configure postfix by default. Modify only: local_recipients_map = luser_relay = info@mydomain.nl and try. I'm going to try myself.... ¡Hold there! It is: "local_recipient_maps", not "local_recipients_map", as you have... could that be all? I'll hope, tell me :-) I tried on mine: local_recipient_maps = luser_relay = fido and it worked. You do not need the domain part in the user name, that's for an external server. -- Cheers, Carlos Robinson
At 21:26 4-2-2004 +0100, Carlos E. R. wrote:
The Wednesday 2004-02-04 at 09:56 +0100, Leen de Braal wrote:
I suppose that you can send mail locally to "info@mydomain.nl", no? Test it. Otherwise, have a look at "usr/share/doc/packages/postfix/html/rewrite.html#luser_relay", I'm out of ideas. Paste a bit of your log, with real addresses modified. I can only offer to have a look at it :-)
Here goes something wrong in fetchmail trying to get the second message from the ISP after a RSET because of unknown user:
fetchmail: forwarding to localhost fetchmail: SMTP> MAIL FROM:
SIZE=957 fetchmail: SMTP< 250 Ok fetchmail: SMTP> RCPT TO: fetchmail: SMTP< 450 : User unknown in local recipient table fetchmail: SMTP error: 450 : User unknown in local recipient table fetchmail: SMTP> RSET fetchmail: SMTP< 250 Ok fetchmail: message dropbox@myisp.nl:1 was not the expected length (837 actual != 957 expected) not flushed Ah. I think the mail server is broken and implements RSET badly. Perhaps it ignores it and continues reading.
fetchmail: POP3> RETR 2 fetchmail: POP3< Test for known user (ldb) fetchmail: POP3> QUIT fetchmail: POP3< fetchmail: client/server protocol error while fetching from mail.myisp.nl fetchmail: 6.2.3 querying mail.myisp.nl (protocol POP3) at Wed Feb 4 09:42:06 2004: poll completed fetchmail: Query status=4 (PROTOCOL) fetchmail: Writing fetchids file. fetchmail: normal termination, status 4 fetchmail: Writing fetchids file.
So here is a reason why the subsequent messages are not fetched: messagesize of first message is changed because of rewritten headers, and fetchmail looses track of the mails in the multidropbox in myisp.nl. How to avoid this??
I don't see how. You could send that query to the fetchmail developers or mail list, to see what can be done. Before that, read the docs to see if there is someway not to send RSET, but simply read the email through, but ignoring it.
You can do something, perhaps: call fetchmail in daemon mode, so that instead of exiting it tries again after the predefined interval. If you are lucky, that mail will be marked "seen" already and ignored.
That was not the case, fetchmail was run every 5 minutes by a cronjob.
Another idea: some servers support IMAP, even if they don't say they do: try. Just change the POP3 with AUTO in the config file. Imap supports much more cleanly skipping mails.
One more, depending on the server - see this from fetchmail docs:
| All these alternatives work in basically the same way | (communicating with standard server daemons to fetch mail | already delivered to a mailbox on the server) except ETRN | and ODMR. The ETRN mode allows you to ask a compliant | ESMTP server (such as BSD sendmail at release 8.8.0 or | higher) to immediately open a sender-SMTP connection to | your client machine and begin forwarding any items | addressed to your client machine in the server's queue of | undelivered mail. The ODMR mode requires an ODMR-capable | server and works similarly to ETRN, except that it does | not require the client machine to have a static DNS.
That would be nice, but I have never seen it.
Second: postfix still refuses mail for unknown users.
Yes, that's the most important thing.
linux:/home/ldb # less /etc/postfix/main.cf | grep -v ^#:
Command "postconf" is more direct :-)
And also more exact, it is the actual configuration as seen by postfix.
mail_spool_directory = /var/mail canonical_maps = hash:/etc/postfix/canonical
I think it is correct, first glance...
I have tried to remove reject_unauth_destination in this line:
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
but this gives me a postfix-throttle. I will dig into the docs about rewrite#luser_relay. I am still missing something.
Test sending an email locally to "info@mydomain.nl", and if it works, repeat from an external account. If that account is unreachable, it would explain why it is failing. In that case, save your configuration, and start afresh, letting Yast configure postfix by default. Modify only:
local_recipients_map = luser_relay = info@mydomain.nl
and try. I'm going to try myself.... ¡Hold there! It is: "local_recipient_maps", not "local_recipients_map", as you have... could that be all? I'll hope, tell me :-)
Good you are well awake. This was it!! How a stupid typo can keep you busy...
I tried on mine:
local_recipient_maps = luser_relay = fido
and it worked. You do not need the domain part in the user name, that's for an external server.
I left it out, and it works now. Mail for unknown users is dropped in info-box.
-- Cheers, Carlos Robinson
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
participants (2)
-
Carlos E. R.
-
Leen de Braal