Re: forwarding mail to another MX on same domain
I just realized that this would not resolve the issue because the remote MX would just redeliver it to the local server which is the final destination of the domain. I'm probably better off with a simple alias domain forward. So while it's not worth considering how to tweak my specific configuration, I'd still be curious to know why the transport map.. [EMAIL PROTECTED]smtp:mx.myexternaldomain.com ..produces a Relay access denied error. Does the relay access need to be specifically allowed for that destination even though the transport is internal by a mapping? Ville
Re: Limiting header_checks by domain or interface
Ville Walveranta a écrit : Is it possible to limit header_checks either by recipient domain or by listening interface? I'd like to remove certain headers, but only from specific domains. You can set a cleanup for each smtpd. something like this: 192.0.2.3:25 smtpd -o cleanup_service_name=myothercleanup ... myothercleanup unixn - n - 0 cleanup -o header_checks=pcre:/etc/postfix/myotherheaderchecks.pcre
Re: forwarding mail to another MX on same domain
Ville Walveranta a écrit : I just realized that this would not resolve the issue because the remote MX would just redeliver it to the local server which is the final destination of the domain. I'm probably better off with a simple alias domain forward. So while it's not worth considering how to tweak my specific configuration, I'd still be curious to know why the transport map.. [EMAIL PROTECTED]smtp:mx.myexternaldomain.com ..produces a Relay access denied error. Does the relay access need to be specifically allowed for that destination even though the transport is internal by a mapping? http://www.postfix.org/postconf.5.html#reject_unauth_destination
Re: forwarding mail to another MX on same domain
Ville Walveranta: I'll continue here since Krosrow's issue has been resolved (so I'm not really hijacking the thread). I now have the following defined in mailbox_transport_maps: [EMAIL PROTECTED]smtp:mx.myexternaldomain.com Yet when I attempt to send mail to the local system at [EMAIL PROTECTED] I get 554 5.7.1 [EMAIL PROTECTED]: Relay access denied quit 221 2.0.0 Bye Why? For Postfix to accept mail for myexternaldomain.com, it must be listed in (exactly) one of the following: mydestination virtual_alias_domains virtual_mailbox_domains relay_domains. For more information see http://www.postfix.org/ADDRESS_CLASS_README.html. Wietse
Re: Postfix and quota clarification
Hi! On Sat, Nov 22, 2008 at 9:53 PM, Wietse Venema [EMAIL PROTECTED] wrote: mouss: Rocco Scappatura a ?crit : Hello, I have a post-office platform based on Postfix-2.5.2+Courier-IMAP-4.0.1-Courier-authlib-0.53+MySQL-5.0.33. Can someone give some hint on how enable (and verify that works) quota on mailboxes? 1- there is no quota support in postfix. However, Postfix supports access maps that can reject mail for over-quota users, if you are willing to periodically add up all the mail each user has. I have been using filesystem quotas for this purpose, and it works just fine. Off course, I have a dedicated filesystem for mail storage. Wietse 2- there is no safe quota support in any MTA. most quota implementations will send a bounce, which may resultin backscatter true. but quotas are necessary: the more disk space the users have, the more garbage they store. 3- if you can queue mail, you can deliver it ;-p 4- disks don't cost too much now. true, but when you have 10k users, the cost of each not so expensive hard drive starts to add, and not only that, in a public organization you can have wait-times of around 6 months just to get a hard drive. Oh, and don't forget: you have plug these hard drives somewhere: every server has they hard drives limit, and you could take a PC and lots of SATA controllers, and build a nice low-cost NAS-like thing, but a few people qualify this as unreliable, they need to spend lots of money on IBM or HP storage systems, and because of the cost, they just don't buy them, and thus: we have a limited amount of disk space :( . 5- if your users abuse mail, destroy their heads, not ours. I don't think my boss let me do that, jejejeje :D c-ya! Ildefonso.
Re: Address Verification Header
Jason Wohlford wrote: On Nov 22, 2008, at 11:41 AM, Noel Jones wrote: But regardless, if you want to evaluate the results of the verification outside of postfix, you really need to do the verification probes outside of postfix. Yes, but I trust postfix. I have some hope of hacking a perl script to integrate with spamassassin. I got no hope of writing my own verify. Unfortunately, I don't see a clear solution. There isn't a clear solution. Your best bets are to either hack postfix to insert the results of the probe in a header (might not be too hard... all the pieces are there already), or to forget it. -- Noel Jones
Use of permit_inet_interfaces?
I now have
smtpd_client_restrictions =
permit_mynetworks
permit_inet_interfaces
check_client_access hash:$config_directory/tables/smtpd_client_access
reject
smtpd_client_restrictions_katharion =
permit_mynetworks
permit_sasl_authenticated
check_client_access
hash:$config_directory/tables/smtpd_client_access_katharion
reject
The latter restricts an interface in master.cf to the relay servers of
an external spam-filtering service:
192.168.1.97:25 inet n - n - - smtpd
-o smtpd_client_restrictions=${smtpd_client_restrictions_katharion}
-o smtpd_recipient_restrictions=${smtpd_recipient_restrictions_katharion}
-o cleanup_service_name=cleanup_katharion
I was under the impression that `permit_inet_interfaces' in
smtpd_client_restrictions would've allowed requests coming *through*
the inet_interfaces (currently defined as 127.0.0.1, 192.168.1.99 –
still in the testing environment) but not from the additional
interface created in master.cf as 192.168.1.97. But apparently this is
not the case; apparently permit_inet_interfaces allows the request
when its IP matches that _of_ the interface, i.e. in this case
127.0.0.1 or 192.168.1.99. When would a request match one of those?
What, in other words, is the use for permit_inet_interfaces?
Since I'm interested in matching the remote clients, I think I need to
create a restriction like the smtpd_client_access_katharion, but in
reverse so that any other client is allowed on the public interface
but not one of the spam filtering service (though nobody is going to
violate that rule so it's a bit of a moot point).
Ville
Re: forwarding mail to another MX on same domain
Couple of messages earlier in this thread I posted the following pcre smtpd_recipient_access table: # reject domains that are served by Katharion # on the generic smtpd interface /(@virtualdomain1\.com| @virtualdomain2\.com| @virtualdomain3\.com| @virtualdomain4\.com| @virtualdomain5\.com)$/ REJECT That was of wrong format. In case someone is reading this later in the archives, here's the corrected version: /virtualdomain1\.com$/ REJECT /virtualdomain2\.com$/ REJECT /virtualdomain3\.com$/ REJECT /virtualdomain4\.com$/ REJECT /virtualdomain5\.com$/ REJECT PCRE statements can't be broken on multiple lines, of course, so if there are many items on the list it's better to break up the boolean statement. Also, I had initially (though not in the earlier post).. /^/ OK .. in the end, thinking that the ones that are not explicitly rejected should be allowed in the context of this PCRE table. But since the table is called from smtpd_recipient_restrictions, such a statement creates an open relay. Ville
