Re: Conditional/soft smtpd restrictions
Am 16.01.2015 um 21:48 schrieb Eugene R: If you're rejecting good mail more than "rarely", you should reevaluate your restrictions. In particular, most built-in HELO checks are likely to reject legit mail, and not terribly effective against current spam bots. The "reject_unknown_client" is also likely to reject wanted mail. Use these with caution. Actually the set I have is surprisingly effective and also surprisingly good in keeping FPs low -- much, much better than anything I saw from SA and DSPAM, and with virtually no server or management overhead. That's why I only want a controlled workaround for misconfigured senders just setup "rbldnsd" and use "permit_dnswl_client" with your own whitelist, that way you can even create different return values of your whitelist and place them to override different stages of your restricitions by trust-levels
Re: Conditional/soft smtpd restrictions
Hello Noel, -Original Message- From: Noel Jones Sent: Saturday, January 17, 2015 12:20 AM You want to conditionally run some extra restrictions based on the outcome of prior restrictions? Some of the existing policy servers do weighted scoring, which gives very similar results. Conditional greylisting? Some of the existing greylisting daemons do that already. Do you have any specific suggestions? I looked at several policy servers and could not find one that could be (natively) configured to do what I want -- and I would like to avoid hacking/patching the internals... In fact, generally I feel that one of the problems with existing policy servers is that there are too many of them, without clear leader or clear comparison available =) Add a bunch of extra info to the policy service protocol? Probably not going to happen without a compelling use-case. Most of the postfix built-in envelope tests are easily recreated in perl from the information already supplied. As I said, I would like to avoid hacking/patching as well as recreating (probably not quite accurately) the tests already available in Postfix. But it may be an option, yes. Not trying to be negative, just trying to understand. Thinking outside the box is what drives projects forward. Yeah, thanks a lot, in fact I asked for alternative suggestions in my original message =) Best wishes Eugene
Re: Conditional/soft smtpd restrictions
On 1/16/2015 2:48 PM, Eugene R wrote: > >> Sounds like you're trying to recreate deep inspection in postfix. >> Use SpamAssassin instead. > > Absolutely no deep inspection, no content inspection at all, just > more flexible / controllable chaining of smtpd restrictions. > > Best wishes > Eugene So what's the end-goal here? You want to conditionally run some extra restrictions based on the outcome of prior restrictions? Some of the existing policy servers do weighted scoring, which gives very similar results. Conditional greylisting? Some of the existing greylisting daemons do that already. Lightweight greylisting? Postscreen after-220 tests do a good imitation of that. Add a bunch of extra info to the policy service protocol? Probably not going to happen without a compelling use-case. Most of the postfix built-in envelope tests are easily recreated in perl from the information already supplied. Not trying to be negative, just trying to understand. Thinking outside the box is what drives projects forward. -- Noel Jones
Re: Conditional/soft smtpd restrictions
Hi Noel, -Original Message- From: Noel Jones Sent: Friday, January 16, 2015 11:29 PM If you're rejecting good mail more than "rarely", you should reevaluate your restrictions. In particular, most built-in HELO checks are likely to reject legit mail, and not terribly effective against current spam bots. The "reject_unknown_client" is also likely to reject wanted mail. Use these with caution. Actually the set I have is surprisingly effective and also surprisingly good in keeping FPs low -- much, much better than anything I saw from SA and DSPAM, and with virtually no server or management overhead. That's why I only want a controlled workaround for misconfigured senders. > I am not sure it is wise to try implementing such complex logic in > Postfix configuration file. But I think it is easier and actually Sounds like you're trying to recreate deep inspection in postfix. Use SpamAssassin instead. Absolutely no deep inspection, no content inspection at all, just more flexible / controllable chaining of smtpd restrictions. Best wishes Eugene
Re: Conditional/soft smtpd restrictions
On 1/16/2015 1:36 PM, Eugene R wrote: > Hi all! > > I have a fairly standard set of smtpd restrictions implemented and > generally I’m very happy with them (very low spam traffic and no > headaches associated with SpamAssassin or DSPAM). > However, once in a while a legitimate message is rejected because > the other side has misconfigured HELO or DNS or the like. Of course, > they really should know better, but I am not always in position to > explain it to them, and their organization may be too complicated to > react properly. As the things stand, it sometimes creates problems > for us rather than for them =) If you're rejecting good mail more than "rarely", you should reevaluate your restrictions. In particular, most built-in HELO checks are likely to reject legit mail, and not terribly effective against current spam bots. The "reject_unknown_client" is also likely to reject wanted mail. Use these with caution. > > I have an idea that seems promising, but from reading the docs I > feel that it is not currently possible. However, maybe it could be > included in the next version or someone could suggest another approach. > Basically the goal is to relax ‘hard’ reject restrictions and run > the mails that fail ‘soft’ restrictions through greylisting or other > filtering, without delaying good mail. Alternately, investigate using postscreen with the "after 220" tests enabled. > I am not sure it is wise to try implementing such complex logic in > Postfix configuration file. But I think it is easier and actually Sounds like you're trying to recreate deep inspection in postfix. Use SpamAssassin instead. -- Noel Jones > more powerful simply to expose the ‘fired’ restrictions to the > policy daemon and let it decide how to handle stuff. > > I imagine a syntax like this may be possible (just wild guess): > restrictions_mynetworks = false > restrictions_sasl_authenticated = false > restrictions_invalid_helo_hostname = false > restrictions_non_fqdn_helo_hostname = false > restrictions_unknown_helo_hostname = true > restrictions_rbl_client_zen_spamhaus_org = false > For performance reasons, probably only the restrictions that are > already evaluated at the point where check_policy_service is called > should be available. This would require something like > "defer_rbl_client zen.spamhaus.org" in main.cf to check the > restriction non-destructively. > > Best wishes > Eugene
Conditional/soft smtpd restrictions
Hi all! I have a fairly standard set of smtpd restrictions implemented and generally I’m very happy with them (very low spam traffic and no headaches associated with SpamAssassin or DSPAM). However, once in a while a legitimate message is rejected because the other side has misconfigured HELO or DNS or the like. Of course, they really should know better, but I am not always in position to explain it to them, and their organization may be too complicated to react properly. As the things stand, it sometimes creates problems for us rather than for them =) I have an idea that seems promising, but from reading the docs I feel that it is not currently possible. However, maybe it could be included in the next version or someone could suggest another approach. Basically the goal is to relax ‘hard’ reject restrictions and run the mails that fail ‘soft’ restrictions through greylisting or other filtering, without delaying good mail. I am not sure it is wise to try implementing such complex logic in Postfix configuration file. But I think it is easier and actually more powerful simply to expose the ‘fired’ restrictions to the policy daemon and let it decide how to handle stuff. I imagine a syntax like this may be possible (just wild guess): restrictions_mynetworks = false restrictions_sasl_authenticated = false restrictions_invalid_helo_hostname = false restrictions_non_fqdn_helo_hostname = false restrictions_unknown_helo_hostname = true restrictions_rbl_client_zen_spamhaus_org = false For performance reasons, probably only the restrictions that are already evaluated at the point where check_policy_service is called should be available. This would require something like "defer_rbl_client zen.spamhaus.org" in main.cf to check the restriction non-destructively. Best wishes Eugene
Re: Primary vs Backup MX?
Wietse Venema: > > * permit_mx_backup > > Permit the request when the local mail system is backup MX for the RCPT > > TO domain, ... > > > > *Safety: as of Postfix version 2.3, permit_mx_backup no longer accepts > > the address when the local mail system is primary MX for the recipient > > domain. I suppose that is still in effect (my previous reply is based on the older implementation). You can specify with permit_mx_backup_networks where the primaries must be located. > > Does this mean a MX record pointing to a mail host w/ permit_mx_backup > > all that's needed to relay to it? You also need relay_recipient_maps or reject_unverified_recipient, otherwise your server will accept non-existent email addresses and will send massive numbers of bounces to innocent people. Wietse
Re: Primary vs Backup MX?
George Ficzeri: > Hello. > > I hope these aren't silly questions: How does Postfix (2.9.6) determine > whether the local mail system is backup or primary MX when > permit_mx_backup is specified in main.cf? Is it just MX record > priorities in DNS? By default it will act as primary or backup MX server, but you can require that primary MX hosts must be in specific local or remote networks with the permit_mx_backup_networks feature. Wietse > http://www.postfix.org/postconf.5.html#permit_mx_backup > * permit_mx_backup > Permit the request when the local mail system is backup MX for the RCPT > TO domain, ... > > *Safety: as of Postfix version 2.3, permit_mx_backup no longer accepts > the address when the local mail system is primary MX for the recipient > domain. > > Does this mean a MX record pointing to a mail host w/ permit_mx_backup > all that's needed to relay to it? >
Primary vs Backup MX?
Hello. I hope these aren't silly questions: How does Postfix (2.9.6) determine whether the local mail system is backup or primary MX when permit_mx_backup is specified in main.cf? Is it just MX record priorities in DNS? http://www.postfix.org/postconf.5.html#permit_mx_backup * permit_mx_backup Permit the request when the local mail system is backup MX for the RCPT TO domain, ... *Safety: as of Postfix version 2.3, permit_mx_backup no longer accepts the address when the local mail system is primary MX for the recipient domain. Does this mean a MX record pointing to a mail host w/ permit_mx_backup all that's needed to relay to it?
Re: Access from $mynetworks denied
On 1/16/2015 3:26 AM, M. Fioretti wrote: > Greetings, > > I have just "inherited" a postfix 2.6.6 server running on a Centos 6 > server, whose postconf -n output is pasted below. > > Everything seems fine to me (but of course any pointer to security > holes, or possibilities for improvement is welcome!) except one > thing. This server must relay email from only two sources: > > a) messages sent through the local webmail interface > b) messages coming from another server some.server.com with a fixed > ip address,xxx.yyy.www.zzz : these are all notification messages > from cron jobs/shell scripts, for several people > > a) is working perfectly, b) isn't. every message from > some.server.com is rejected as follows: > > Jan 16 10:04:41 server postfix/smtpd[11561]: NOQUEUE: reject: RCPT > from some.server.com[xxx.yyy.www.zzz]: 554 5.7.1 > : Client host rejected: Access > denied; from= to= > proto=ESMTP helo= This indicates a check_client_access table that lists either the hostname or IP with REJECT. I don't see any check_client_access tables below. Are you sure you're looking at the correct postfix configuration? Are there some overrides listed in master.cf? -- Noel Jones > > > Yes, I **know** it is surely something trivial, but right now I am > obviously unable to see it. I have done several postfix > configurations in the past, but this time I seem back to square one... > > What am I missing? > > Thanks in advance, > Marco > > > command_directory = /usr/sbin > config_directory = /etc/postfix > daemon_directory = /usr/libexec/postfix > debug_peer_level = 2 > disable_vrfy_command = yes > html_directory = /usr/share/doc/postfix-2.4.3-documentation/html > inet_interfaces = all > mail_owner = postfix > mailq_path = /usr/bin/mailq.postfix > manpage_directory = /usr/share/man > mydestination = $myhostname, localhost > mydomain = $myhostname > myhostname = a.mx.example.com > mynetworks = 127.0.0.0/8, xxx.yyy.www.zzz > myorigin = $mydomain > newaliases_path = /usr/bin/newaliases.postfix > queue_directory = /var/spool/postfix > readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme > relay_domains = > relayhost = > sample_directory = /etc/postfix > sendmail_path = /usr/sbin/sendmail.postfix > setgid_group = postdrop > smtpd_helo_required = yes > smtpd_helo_restrictions = > smtpd_recipient_restrictions = permit_mynetworks, > reject_invalid_hostname, reject_non_fqdn_hostname, > reject_non_fqdn_sender, reject_non_fqdn_recipient, > reject_unknown_sender_domain, > reject_unknown_recipient_domain,permit_mynetworks, > > permit_sasl_authenticated, > reject_unauth_destination, > check_helo_access hash:/etc/postfix/reject_own_helo > smtpd_sasl_auth_enable = yes > smtpd_sasl_path = /var/spool/postfix/private/auth > smtpd_sasl_type = dovecot > smtpd_tls_auth_only = yes > smtpd_tls_cert_file = /etc/myssl/mycert.pem > smtpd_tls_key_file = /etc/myssl/mycert.pem > smtpd_tls_loglevel = 1 > smtpd_tls_security_level = may > strict_rfc821_envelopes = yes > unknown_address_reject_code = 554 > unknown_client_reject_code = 554 > unknown_hostname_reject_code = 554 > unknown_local_recipient_reject_code = 550 > virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map > virtual_gid_maps = static:5000 > virtual_mailbox_base = /var/mail/mymail_storage > virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map > virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map > virtual_transport = procmail > virtual_uid_maps = static:5000 >
Re: postscreen stopped working today for a few hours
btb: > i guess i consider lost logs to be a bug - i'll submit a bug report to > ubuntu for this. in your opinion, would this be something the postfix > package maintainer should address, or the syslog-ng packager maintainer > [or is it just the admin's fault]? Postfix, with chroot turned on, requires a syslog socket under /var/spool/postfix (the location that queue_directory is set to). This requires action by two parties. 1) The syslog server maintainer needs to provide a method that allows other programs to request an additional syslog socket. 2) The Postfix maintainer needs to use the method described in 1). This is not new; but in 16 years since the public release it has yet to be resolved in a satisfactory manner. This cannot be built into Postfix, because there is no API to determine the location of the syslog socket or to determine that the syslog server is restarted (the syslog() function does not return a result value). Wietse
Re: postscreen stopped working today for a few hours
On Fri, Jan 16, 2015 at 10:42:54AM -0500, btb wrote: > I guess I consider lost logs to be a bug - I'll submit a bug report to > ubuntu for this. In your opinion, would this be something the postfix > package maintainer should address, or the syslog-ng packager maintainer [or > is it just the admin's fault]? If a distribution ships Postfix packages with chroot enabled by default, it must also arrange for syslogd or equivalent to keep a log socket in each Postfix chroot jail (I say "each", because with multiple instances each queue directory is a separate jail). They'd have to patch "postmulti-script" to make the appropriate syslog configuration changes. At some point the Debian and Ubuntu distributions might finally reconsider their chroot-by-default decision, it hurts a lot more than it helps. [ Scott K.? LaMont J.? Any plans? ] -- Viktor. P.S. Things were much simpler when syslog(3) was UDP to localhost. No log sockets in the file-system. The UDP namespace is unified across chroot jails.
Re: using ppymilter in Postfix
> Change permissions to 700 and ran the script. It gave no errors, which is > good. However, using ss to check which ports are in use doesn't show port > 12000(Which I would expect) lsof -Pni :12000 Christian -- Bachelor of Science Informatik Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: postscreen stopped working today for a few hours
On 2015.01.16 09.43, wie...@porcupine.org (Wietse Venema) wrote: btb: postconf -Mf smtp inet n - - - 1 postscreen Yep, it's chrooted. You need to configure syslog to add a log socket to the jail, or turn off chroot. during this period, postfix activity from all other postfix processes is getting logged successfully, most of which are chrooted, and postscreen is logging fine outside of this one period. i think chroot is not the You are missing an important detail. On a busy server postscreen will run forever. It will never reconnect to the new syslog server. On a busy or idle server, smtpd runs only for a few minutes. The next smtpd process will automatically to the new syslog server. I am 99.99% certain that chroot is the problem here. thanks, i'll concede this analysis. i don't have enough forensic evidence to confirm but i now believe that the symptom of mail appearing to get through which shouldn't have was the red herring [sorry viktor!] - that the client in question was added to postscreen_access_list just after this, and it was just a coincidence of timing. i guess i consider lost logs to be a bug - i'll submit a bug report to ubuntu for this. in your opinion, would this be something the postfix package maintainer should address, or the syslog-ng packager maintainer [or is it just the admin's fault]? -ben
Re: postscreen stopped working today for a few hours
Am 16.01.2015 um 15:33 schrieb Wietse Venema:
Wietse Venema:
FreeBSD:
# mkdir -p /var/spool/postfix/var/run
# syslogd -l /var/spool/postfix/var/run/log
Linux, OpenBSD:
# mkdir -p /var/spool/postfix/dev
# syslogd -a /var/spool/postfix/dev/log
Except that on some systems systemd is taking over every service,
like the Borg ("Resistance is futile. You will be assimilated.")
on the other hand you get much more logs on recent systemd
distributions, even stdout normally not make it to the syslog is now
catched by journald
with chroot and bind-mounts you can even get important devices by just
bind-mount /dev in the new chroot without leak the complete /dev tree
and no longer need to consider each and every seperated
PrivateDevices=
Takes a boolean argument. If true, sets up a new /dev namespace for the
executed processes and only adds API pseudo devices such as /dev/null,
/dev/zero or /dev/random (as well as the pseudo TTY subsystem) to it,
but no physical devices such as /dev/sda. This is useful to securely
turn off physical device access by the executed process. Defaults to
false. Enabling this option will also remove CAP_MKNOD from the
capability bounding set for the unit (see above), and set
DevicePolicy=closed (see systemd.resource-control(5) for details). Note
that using this setting will disconnect propagation of mounts from the
service to the host (propagation in the opposite direction continues to
work). This means that this setting may not be used for services which
shall be able to install mount points in the main mount namespace.
Re: postscreen stopped working today for a few hours
btb: > >>> postconf -Mf > >> smtp inet n - - - 1 postscreen > > > > Yep, it's chrooted. You need to configure syslog to add a log > > socket to the jail, or turn off chroot. > > during this period, postfix activity from all other postfix processes is > getting logged successfully, most of which are chrooted, and postscreen > is logging fine outside of this one period. i think chroot is not the You are missing an important detail. On a busy server postscreen will run forever. It will never reconnect to the new syslog server. On a busy or idle server, smtpd runs only for a few minutes. The next smtpd process will automatically to the new syslog server. I am 99.99% certain that chroot is the problem here. Wietse
Re: Access from $mynetworks denied
M. Fioretti: > On 2015-01-16 14:18, li...@rhsoft.net wrote: > > > *do not* mask public informations, especially if you fail to mask it > > on all places... > > Indeed I did. As I said in or between the lines I'm not particularly > "present" these days... So yes, that is the ONLY IP address involved in > $mynetworks and in everything else I wrote/pasted in my original email. > What next? $ postconf -n | grep the.ip.addr.ess Perhaps you typo-ed the address in one place. $ find / -name main.cf Perhaps smtpd(8) is using a different main.cf file than the one reported with "postconf -n". Wietse
Re: postscreen stopped working today for a few hours
On 2015.01.15 22.21, Viktor Dukhovni wrote: On Thu, Jan 15, 2015 at 09:57:53PM -0500, b...@bitrate.net wrote: i happened to notice that on one of our two mxes, no postscreen activity was logged between 06:25:09 and 11:54:42: Jan 15 06:25:09 mta2 postfix/postscreen[22371]: DISCONNECT [103.242.116.92]:37543 Jan 15 11:54:42 mta2 postfix/postscreen[25663]: CONNECT from [209.85.213.183]:41380 to [10.3.70.6]:25 Note the change of pid! You probably ran "postfix reload" right around then. no postfix reload, there, no. those two log entries are 5+ hours apart. it was just to illustrate the time period. but other postfix activity was *logging* normally, and mail was flowing normally: all of this makes it seems like postscreen wasn't working during that period, and i'm wondering why that might be. Actually it was working, just wasn't logging! i thought so too. it seemed the most obvious answer, but i began to change my mind when i saw mail getting accepted which should have been rejected by postscreen_access_list. it also doesn't explain why postfix was logging other process activity successfully during that time. I avoid sending SIGHUP to the log daemon, and use syslog-ng with date based output files which are expired by scripts other than logrotate, that way I don't lose any log messages. thanks for this suggestion, we may do that. postconf -Mf smtp inet n - - - 1 postscreen Yep, it's chrooted. You need to configure syslog to add a log socket to the jail, or turn off chroot. during this period, postfix activity from all other postfix processes is getting logged successfully, most of which are chrooted, and postscreen is logging fine outside of this one period. i think chroot is not the culprit here. -ben
Re: using ppymilter in Postfix
Andy Kannberg: > Change permissions to 700 and ran the script. It gave no errors, which is > good. However, using ss to check which ports are in use doesn't show port > 12000(Which I would expect) Maybe you should be looking for "entextxid". $ grep 12000 /etc/services entextxid 12000/tcp # IBM Enterprise Extender SNA XID Exchange entextxid 12000/udp # IBM Enterprise Extender SNA XID Exchange > I see no message whatsoever in /var/log/maillog that the milter is used. Am > I missing something ? Output from the "postconf -n" command. Wietse
Re: postscreen stopped working today for a few hours
Wietse Venema:
> Viktor Dukhovni:
> > > >postconf -Mf
> > > smtp inet n - - - 1 postscreen
> >
> > Yep, it's chrooted. You need to configure syslog to add a log
> > socket to the jail, or turn off chroot.
>
> FreeBSD:
>
> # mkdir -p /var/spool/postfix/var/run
> # syslogd -l /var/spool/postfix/var/run/log
>
> Linux, OpenBSD:
>
> # mkdir -p /var/spool/postfix/dev
> # syslogd -a /var/spool/postfix/dev/log
Except that on some systems systemd is taking over every service,
like the Borg ("Resistance is futile. You will be assimilated.").
Wietse
Re: Access from $mynetworks denied
On 2015-01-16 14:18, li...@rhsoft.net wrote: *do not* mask public informations, especially if you fail to mask it on all places... Indeed I did. As I said in or between the lines I'm not particularly "present" these days... So yes, that is the ONLY IP address involved in $mynetworks and in everything else I wrote/pasted in my original email. What next? Thanks -- http://mfioretti.com
Re: Building a spam honeypot, or need to exclude domains/users from RBLs
Hi, Is there any existing documentation on how to create a spam honeypot as it relates to doing it on a production server, or do I really need to just create a virtual machine with a basic postfix configuration to do this? You can use postfix smtp-sink to implement a simple spam collector. It never rejects mail, it never delivers mail, it only saves all mail to file. smtp-sink is included with Postfix source code. Thanks guys for your help. I'll investigate. Thanks, Alex
Re: using ppymilter in Postfix
Ok, so far I've figured out this:
I added this to the main.cf :
smtpd_milters = inet:localhost:12000
milter_protocol = 6
I used the example script of ppymilter from the Wiki (
https://code.google.com/p/ppymilter/wiki/PPyMilter)
I only modified it to to use tcp port 12000:
#!/usr/bin/python
import asyncore
from ppymilter import ppymilterbase, ppymilterserver
# (or just "import ppymilterbase, ppymilterserver" depending on your
# sys.path)
class NoBccMilter(ppymilterbase.PpyMilter):
def __init__(self):
ppymilterbase.PpyMilter.__init__(self)
self.CanAddHeaders()
self.__mutations = []
# obviously this doesn't work (well) with mail groups
def OnRcptTo(self, cmd, rcpt_to, esmtp_info):
self.__mutations.append(self.AddHeader('To', rcpt_to))
return self.Continue()
def OnEndBody(self, cmd):
tmp = self.__mutations
self.__mutations = []
return self.ReturnOnEndBodyActions(tmp)
def OnResetState(self):
self.__mutations = []
if __name__ == '__main__':
ppymilterserver.AsyncPpyMilterServer(12000, NoBccMilter)
asyncore.loop()
Change permissions to 700 and ran the script. It gave no errors, which is
good. However, using ss to check which ports are in use doesn't show port
12000(Which I would expect)
I see no message whatsoever in /var/log/maillog that the milter is used. Am
I missing something ?
cheers,
Andy
2015-01-08 15:20 GMT+01:00 Andy Kannberg :
> Hi,
>
> I am looking how to use ppymilter in Postfix. Using pymilter is explained
> in the Postfix docs ( http://www.postfix.org/MILTER_README.html#config )
> , but I can't find how to do the same for ppymilter. Anyone can send me in
> the right direction ?
>
> cheers,
> Andy
>
Re: postscreen stopped working today for a few hours
Viktor Dukhovni: > > >postconf -Mf > > smtp inet n - - - 1 postscreen > > Yep, it's chrooted. You need to configure syslog to add a log > socket to the jail, or turn off chroot. FreeBSD: # mkdir -p /var/spool/postfix/var/run # syslogd -l /var/spool/postfix/var/run/log Linux, OpenBSD: # mkdir -p /var/spool/postfix/dev # syslogd -a /var/spool/postfix/dev/log Wietse
Re: Access from $mynetworks denied
Am 16.01.2015 um 10:26 schrieb M. Fioretti: I have just "inherited" a postfix 2.6.6 server running on a Centos 6 server, whose postconf -n output is pasted below. Everything seems fine to me (but of course any pointer to security holes, or possibilities for improvement is welcome!) except one thing. This server must relay email from only two sources: a) messages sent through the local webmail interface b) messages coming from another server some.server.com with a fixed ip address,xxx.yyy.www.zzz : these are all notification messages from cron jobs/shell scripts, for several people a) is working perfectly, b) isn't. every message from some.server.com is rejected as follows: Jan 16 10:04:41 server postfix/smtpd[11561]: NOQUEUE: reject: RCPT from some.server.com[xxx.yyy.www.zzz]: 554 5.7.1 : Client host rejected: Access denied; from= to= proto=ESMTP helo= "xxx.yyy.www.zzz" is not really helpful because it's possible that you overlooked a small typo and hide us that information *do not* mask public informations, especially if you fail to mask it on all places because you leaked 212.110.184.219 aynways but only at one place and so we miss the context
Re: proxymap error with mysql access table
Hello thank you Viktor for your advice, it was very helpful. I do hold temporarily incoming mails for migrating users with a transport table with retry: transport. As you said it's better clean than with smtpd_restrictions avec hold queue - no need to release manually hold mails - no trouble with multi-recipients mails Thank you again. -- Arnaud a.ja...@free.fr I am guessing English is a 'second language' for you. The error messages above are remarkably precise as to the nature of the problem, and what you should do. Specifically: Append the new table to proxy_read_maps (list it in proxy_read_maps as instructed in the log message): # postconf -e "$(postconf proxy_read_maps), proxy:mysql:/etc/postfix/users_hold_mail_migration_zimbra.mysql" Finally, I strongly recommend against "HOLD" in smtpd_restrictions for your migration use-case. It is flawed in multiple ways: * Holds too much mail, when messages have multiple recipients. some of whom are not being migrated. * Fails to hold mail where the target user receives the mail via an alias or list. * Makes it difficult to release mail in a safe way, requiring careful manual manipulation of the HOLD queue. Instead, configure per-user transport entries with "defer" as the transport: main.cf: # Use MySQL if you like # transport_maps = some:table # Logical content, possible in a database of some sort # transport: # Make sure to cover all domains for which the user receives mail # after rewriting (not aliases, rewritten addresses ready for delivery). # joe.u...@example.comretry:4.2.1 Mailbox maintenance in progress See: http://tools.ietf.org/html/rfc3463#section-3.3 http://www.postfix.org/error.8.html By using transport_maps not only do you avoid all the problems with HOLD, but you also don't need to customize proxy_read_maps, because $transport_maps is there by default. Plus mail is delivered automatically, once the table entry is removed. You can optionally enable or disable delay notices to suit your taste. http://www.postfix.org/postconf.5.html#delay_warning_time -- Viktor.
Access from $mynetworks denied
Greetings, I have just "inherited" a postfix 2.6.6 server running on a Centos 6 server, whose postconf -n output is pasted below. Everything seems fine to me (but of course any pointer to security holes, or possibilities for improvement is welcome!) except one thing. This server must relay email from only two sources: a) messages sent through the local webmail interface b) messages coming from another server some.server.com with a fixed ip address,xxx.yyy.www.zzz : these are all notification messages from cron jobs/shell scripts, for several people a) is working perfectly, b) isn't. every message from some.server.com is rejected as follows: Jan 16 10:04:41 server postfix/smtpd[11561]: NOQUEUE: reject: RCPT from some.server.com[xxx.yyy.www.zzz]: 554 5.7.1 : Client host rejected: Access denied; from= to= proto=ESMTP helo= Yes, I **know** it is surely something trivial, but right now I am obviously unable to see it. I have done several postfix configurations in the past, but this time I seem back to square one... What am I missing? Thanks in advance, Marco command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 disable_vrfy_command = yes html_directory = /usr/share/doc/postfix-2.4.3-documentation/html inet_interfaces = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost mydomain = $myhostname myhostname = a.mx.example.com mynetworks = 127.0.0.0/8, xxx.yyy.www.zzz myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme relay_domains = relayhost = sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_helo_required = yes smtpd_helo_restrictions = smtpd_recipient_restrictions = permit_mynetworks, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain,reject_unknown_recipient_domain,permit_mynetworks, permit_sasl_authenticated,reject_unauth_destination, check_helo_access hash:/etc/postfix/reject_own_helo smtpd_sasl_auth_enable = yes smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/myssl/mycert.pem smtpd_tls_key_file = /etc/myssl/mycert.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = may strict_rfc821_envelopes = yes unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map virtual_gid_maps = static:5000 virtual_mailbox_base = /var/mail/mymail_storage virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map virtual_transport = procmail virtual_uid_maps = static:5000 -- http://mfioretti.com
