Customizing fetchmailrc.py

UCS - Univention Corporate Server
,
#1

Hello,

I try to customize the creation of the/etc/fetchmailrc file and edited /usr/lib/univention-directory-listener/system/fetchmailrc.py.
But it seems to be the wrong file, because the new created “poll” requests do not show up my patched values, but the default ones.
Which file do I need to edit?

Background: I have to change fetchmail from using postfix to use kopano-dagent by changing the value "here" to mda "/usr/sbin/kopano-dagent %s"

Any help appreciated.

Christian.

Addition: an update-resistent solution is a must …

1 Like
#3

no one any idea, how to correctly patch fetchmail?

#4

Hey,

I’m wondering why you would need to modify the fetchmail configuration in the first place. In a regular UCS+Kopano setup Postfix knows how to deliver local mail via Kopano. Therefore the normal way of using fetchmail should work out of the box: fetchmail → local postfix → Kopano. Such a setup wouldn’t require modification of templates or configuration files at all.

An additional benefit is that Postix remains the central place all mails go through, both incoming and outgoing mails, making it easy to integrate solutions such as anti-virus or legally-mandated archival. If you let fetchmail deliver directly to Kopano you circumvent such solutions; e.g. incoming mails wouldn’t be archived.

So why do you want to circumvent Postfix in the first place?

Kind regards,
mosu

#5

Hey, mosu,

Because the current circumstances make it necessary.
This server only handles about 10% of the users, that use a specific mail domain.
If an UCS/Kopano user wants to write an email to an user, who isn’t working with this server, the mail needs be be sent out to the mailserver responsible for this domain.
There are two ways to handle this.

  1. I have to add all users to this UCS and add transportation rules for 90% of the users to sent their mails to a different server, or
  2. I tell postfix to send everything to the main mailserver and receive the mails for those 10% via fetchmail and direct delivery via dagent.

And that’s the reason, why I need to patch the fetchmail-script, because it wouldn’t work in any other way if I don’t want to add all users to this system and add transportation rules for those 90% not using this server.

Kind regards, Christian.

#6

Hey,

Easy: define a transport mapping for that domain for Postfix. No need to add each user; you can add whole domains. For example:

ucr set 'mail/maps/transport/a_unique_name=that.doma.in smtp:1.2.3.4'

How many different domains do you happen to have?

m.

#7

Hey,

or do it the other way around: set the relay host for Postfix to the external server and configure Postfix to only be the final destination for that domain whose users do reside on the Kopano server. No need for direct delivery via the dagent either.

m.

#8

No, not that easy … this is exaclty, what I’ve tried before resulting in fetchmail fetches the mails from domain.com -> postfix sends those mails directly backwards to domain.com.

I’m afraid, you didn’t understand the domain problem … it’s only one domain, which is used inside and outside of this server. 10% of the users are on the server but need to reach the other 90% of the users with the very same domain email-address.

#9

Hey,

oh, I misunderstood, it seems. I thought that the users belonged to different domains; one domain is handled by the Kopano server, others by other servers.

However, you can still make this fully automatic. The information which users reside on the Kopano server is available in the LDAP directory, after all. It’s just a matter of making Postfix use the information correctly.

In this case you should be able to set up the following:

  1. Configure Postfix to be the final destination for the domain all users belong to. This should already be the case.
  2. Define a default transport as the fallback. For that create a file, e.g. /etc/postfix/foreign_users_transport, with the following content: mydoma.in smtp:1.2.3.4
  3. Define an LDAP lookup that returns lmtp:localhost:2003 for all users that should reside on the LDAP server. You can use e.g. /etc/postfix/ldap.virtual_mailbox as the basis. The important thing is to modify result_format so that it always returns the LMTP transport: result_format = lmtp:localhost:2003
  4. Set Postfix’s virtual_mailbox_maps parameter to first search the LDAP table created in step 3 and next the default transport hash table created in step 2.

What should happen is:

  1. An email arrives for on-kopano@mydoma.in. Postfix accepts because it is the final destination for that domain.
  2. Postfix wants to deliver it locally and looks up the mailbox transport to use. It sees that virtual_mailbox_maps is set and tries each of the maps listed there in order.
  3. The first map will yield a match in the search for on-kopano@mydoma.in. Postfix takes the result of that match, which will be lmtp:localhost:2003, as the definition for the transport to use.
  4. Postfix delivers via LMTP to Kopano.

Similarly for a user not residing on Kopano:

  1. An email arrives for not-on-kopano@mydoma.in. Postfix accepts because it is the final destination for that domain.
  2. Postfix wants to deliver it locally and looks up the mailbox transport to use. It sees that virtual_mailbox_maps is set and tries each of the maps listed there in order.
  3. The first map will not yield a match for not-on-kopano@mydoma.in. Postfix continues with the next map.
  4. The map with mydoma.in smtp:1.2.3.4 yields a match for that whole domain and therefore for the user, too.
  5. Postfix delivers via SMTP to 1.2.3.4, even though it isn’t local.

Kind regards,
mosu

#10

cool, ty.
Will try this in the next days.

#11

Hey, Moritz,

one part of this doesn’t work, unfortunatelly.
Sending mails to external users result in the following error message:

Unfortunately, kopano-spooler was unable to deliver your mail to the/some of the recipient(s).
You may need to contact your e-mail administrator to solve this problem.

Recipients that failed permanently:
	 <external-user@domain.de>

Any following idea?

Best regards and thanks for now,
Christian.

#12

Hey,

The spooler doesn’t attempt delivery, it only attemps to pass the message off to Postfix which does the transfer/delivery. Therefore the Postfix log messages from the around the failed attempt would be helpful.

m.

#13

User not found and giving up … :frowning:

Apr 27 13:27:24 kopano postfix/smtpd[27466]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 550 5.1.1 <external-user@domain.de>: Recipient address rejected: User unknown in virtual mailbox table; from=<internal-user@domain.de> t
o=<external-user@domain.de> proto=ESMTP helo=<kopano.domain.de>
Apr 27 13:27:24 kopano kopano-spooler[27500]: RCPT line gave SMTP error 550 5.1.1 <external-user@domain.de>: Recipient address rejected: User unknown in virtual mailbox table. (no retry)

main.cf:

virtual_mailbox_maps = ldap:/etc/postfix/ldap.virtual_mailbox_local,
        hash:/etc/postfix/foreign_users_transport
#14

Hey @Moritz_Bunkus ,

do you have another idea solving this problem?

tyvm in advanced,
Christian.

#15

back to the beginning …
I found out, that I have to restart the univention-directory-listener service after patching the script, mentioned in the first post.

I prevented modifications to this file via
chattr +i /usr/lib/univention-directory-listener/system/fetchmailrc.py

Hope Univention won’t update this script too often :wink:

Thanks in advanced,
Christian.

If someone needs this patch, too:

# diff /usr/lib/univention-directory-listener/system/fetchmailrc.py /usr/lib/univention-directory-listener/system/fetchmailrc.py.backup
116c116
< 		flist.append("poll %s with proto %s auth password user '%s' there with password '%s' \"mda /usr/sbin/kopano-dagent %s\" %s %s #UID='%s'\n" % (
---
> 		flist.append("poll %s with proto %s auth password user '%s' there with password '%s' is '%s' here %s %s #UID='%s'\n" % (
121c121
<                         new['uid'][0],
---
> 			new['mailPrimaryAddress'][0],
Mastodon