Re: Writing pcre expressions.
* Miguel Da Silva - Centro de Matemática [EMAIL PROTECTED]: Dear users, I'm dealing with backscatter and trying to write some expressions to use in body_checks. I could not see how to write it down: if the From header has a e-mail of my network, then the Message-ID must possess a domain.com part (let's suppose domain.com is the local domain). You can't. Use a content_filter -- Ralf Hildebrandt ([EMAIL PROTECTED]) [EMAIL PROTECTED] Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de I'm looking for a job Intel has announced its next chip: the Repentium. -Anon.
Re: Just one user recieving spam.
Noel Jones wrote: Miguel Da Silva - Centro de Matemática wrote: Noel Jones escribió: Miguel Da Silva - Centro de Matemática wrote: Dear users, today an user told me he was recieving too many spam in a very short period of time. I took a look at the log files and what he told me is true. :( But... it just happens to him, nothing else is recieving spam. The server is running Postfix + SpamAssassin + Clamav and the filters seems to run fine. I can see many warnings about blocked spam. The symptons are too many connections trying to send mail to this user. Those connections come from all over the world. Any suggestion?! Greetings. If these are non-delivery notices of mail he didn't send, see the BACKSCATTER_README for suggestions on blocking it. http://www.postfix.org/BACKSCATTER_README.html Thank you... it's really backscatter. Let's work with it now. Greetings. Those usually do not get blocked by RBLs and other usual tactics because they come from legit but poorly configured mail servers. ips.backscatterer.org is an RBL that targets backscatter sources. http://www.backscatterer.org/ To limit the false positives, only reject mail if it looks like a bounce. something like this: # main.cf smtpd_sender_restrictions = regexp:/etc/postfix/sender.regexp # sender.regexp # check null sender bounces /^$/ reject_rbl_client ips.backscatterer.org better do this in data restrictions to avoid blocking SAV sources. $ host lists.sourceforge.net lists.sourceforge.net has address 66.35.250.206 $ host 206.250.35.66.ips.backscatterer.org 206.250.35.66.ips.backscatterer.org has address 127.0.0.2
Re: Transport Based on Destination MX record and not Destination Domain?
Rodre Ghorashi-Zadeh wrote: Yes, that's fine. Although it would be easier to just set smtpd_delay_reject back to it's default of yes, or remove it from your config entirely. Yes, I changed it around and that allowed me to specify the map in smtpd_sender_restrictions= Just one question so I can better my understanding of postfix, does it not make logical sense to have the filter be a smtpd_recipient_restrictions because it is being applied to the recipient address, or I am understanding these values backwards? smtpd_mumble_restrictions apply at stage mumble. it doesn't mean they check the mumble field. so at recipient stage (RCPT TO command), you can check the client, the helo, the sender and the recipient. at the sender stage (MAIL FROM command), you can check the client, the helo and the sender. ... etc. but when you use the default smtpd_delay_reject, all checks are done at recipient stage, so you can put your checks wherever you want. a common choice is to put all anti-uce checks under smtpd_recipient_restrictions (so as to have an easily manageable linear list of checks, and not need to repeat whitelisting checks), and to put checks that are not for whitelisting or blocking uce under other restrictions. This prevents accidental errors that make you an open relay (OK in a map before reject_unauth_destination) or that cause all anti uce checks to be skipped (accidentally I mean). Also, when using maps like hash that do not allow for a default action (you can't do: * do_foo_bar), you can use other restrictions to implement this. for example smtpd_helo_restrictions = check_sender_access hash:/etc/postfix/test reject == test example.com OK This implements the (unrealistic) rule reject if the sender is not in example.com.
Re: *Slightly OT* DNSBL Opinions.
On Tue, Aug 19, 2008 at 09:27:39PM -0400, Adam C. Mathews wrote: Presenting using the following blacklists... dul.dnsbl.sorbs.net psbl.surriel.com zen.spamhaus.org These do a good job for me, but I wanted to look for opinions on a couple additional ones. Specifically look for false-positive opinions, adding additional DNS lookups isn't much concern to me. The two I am looking at are ... hostkarma.junkemailfilter.com combined.rbl.msrbl.net The following site gives their own stats for a number of public DNSBL's: http://stats.dnsbl.com/ Might be interesting for comparison. Geert
advanced mysql lookup
Hello,
I would like to add further condition for delivery of email messages.
In my main.cf I have this setting:
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-transport.cf
where mysql-trasport.cf contains:
select_field = domain
where_field = domain
additional_conditions = and active = 1
I would like to do so that a message is delivered localy only if the
'trasport' for the domain specified by the domain part of the recipient,
is the local server. Otherwise the message have to be forwarded to the
responsible post office server for the recipient domain.
So I have to add the condition:
additional_conditions = and active = 1 and
transport='smtp:host.domain.tld'
where 'host.domain.tld' is the name of local machine.
Now I would like to make safer the lookup table configuration. So I have
thought of modify the additional condition so:
additional_conditions = and active = 1 and LOWER(transport) in
('smtp:`hostname -f`', 'smtp:[`hostname -i`]')
But postfix does not interpolate the shell command..
Is there a way to make safer my lookup condition?
TIA,
rocsca
Re: advanced mysql lookup
Rocco Scappatura wrote:
Hello,
I would like to add further condition for delivery of email messages.
In my main.cf I have this setting:
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-transport.cf
where mysql-trasport.cf contains:
select_field = domain
where_field = domain
additional_conditions = and active = 1
I would like to do so that a message is delivered localy only if the
'trasport' for the domain specified by the domain part of the recipient,
is the local server. Otherwise the message have to be forwarded to the
responsible post office server for the recipient domain.
So I have to add the condition:
additional_conditions = and active = 1 and
transport='smtp:host.domain.tld'
where 'host.domain.tld' is the name of local machine.
Now I would like to make safer the lookup table configuration. So I have
thought of modify the additional condition so:
additional_conditions = and active = 1 and LOWER(transport) in
('smtp:`hostname -f`', 'smtp:[`hostname -i`]')
But postfix does not interpolate the shell command..
no, postfix does not interpret shell, perl, python, php, java, ... code ;-p
Is there a way to make safer my lookup condition?
you could try playing with
SUBSTRING_INDEX(USER(), '@', -1)
but it is safer to use a script (or a makefile) to generate the .cf file
on each machine.
one verify.db with two postfix instances?
Hello list, I use Postfix 2.4.3 on two (actually four, but let's assume two) mailgateways. Both do recipient verification and cache the results with the address_verify_map (verify.db). Sometimes it happens that a foreign server tries to deliver a message and gets a 4xx response from one of my servers because the recipient verification doesn't finish in time. Then it waits some time and tries the other one. From that one it gets a 4xx response, too, because the second server doesn't know that the first server has allready done the recipient verification and does it again by itself. This process delays the delivery of a message and I like to avoid that. My idea: Is it possible to use one verify.db, let's say on a NFS share, with two (or more) postfix servers? Or will it produce problems with accessing the file? ++ |postfix server 1|+ ++|+-+ +|verify.db| ++|+-+ NFS |postfix server 2|+ ++ My postconf -n output: 2bounce_notice_recipient = censored address_verify_map = btree:/etc/postfix/verify address_verify_sender = alias_maps = hash:/etc/mx/aliases, hash:/etc/mx/report_aliases body_checks = regexp:/etc/mx/body_checks bounce_notice_recipient = censored bounce_queue_lifetime = 1d bounce_size_limit = 1 command_directory = /usr/sbin config_directory = /etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/lib/postfix default_process_limit = 300 delay_notice_recipient = censored disable_vrfy_command = yes error_notice_recipient = censored header_checks = regexp:/etc/mx/header_checks html_directory = no lmtp_connect_timeout = 1 mail_owner = postfix mailbox_size_limit = 20 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man maximal_queue_lifetime = 5d mydestination = $myhostname localhost.$mydomain mydomain = censored mynetworks = 127.0.0.0/8 /etc/mx/networks newaliases_path = /usr/bin/newaliases parent_domain_matches_subdomains = fast_flush_domains,mynetworks,relay_domains queue_directory = /var/spool/postfix queue_minfree = 1 readme_directory = /usr/share/doc/packages/postfix/README_FILES recipient_bcc_maps = hash:/etc/mx/recipient_bcc recipient_canonical_classes = envelope_recipient recipient_canonical_maps = hash:/etc/mx/recipient_canonical relay_domains = $mydestination /etc/mx/domains relocated_maps = hash:/etc/mx/relocated sample_directory = /usr/share/doc/packages/postfix/samples sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtpd_client_connection_count_limit = 15 smtpd_client_connection_rate_limit = 30 smtpd_client_restrictions = check_client_access hash:/etc/mx/client_access permit_mynetworks reject_unknown_reverse_client_hostname permit smtpd_data_restrictions = reject_unauth_pipelining permit smtpd_error_sleep_time = 0 smtpd_etrn_restrictions = reject smtpd_hard_error_limit = 5 smtpd_helo_required = yes smtpd_helo_restrictions = reject_invalid_helo_hostname permit smtpd_recipient_restrictions = reject_non_fqdn_recipient reject_unknown_recipient_domain check_recipient_access hash:/etc/mx/recipient_access permit_mynetworks check_recipient_access reject_unauth_destination permit smtpd_sender_restrictions = reject_non_fqdn_sender check_sender_access hash:/etc/mx/sender_access reject_unknown_sender_domain permit strict_rfc821_envelopes = yes transport_maps = hash:/etc/mx/transport unknown_address_reject_code = 550 unverified_recipient_reject_code = 550 Thanks for help. Greetings Stefan
Questions concerning TLS
I am trying to implement TLS on our server for a client requirement. I believe I have the TLS settings correct, but I am not certain about what I am seeing in the logs and I am uncertain as to how to know if a message was delivered using TLS. Is there anything in the message headers that would indicate that it was delivered using TLS? I have the below log entries on some outgoing messages. I am certain that the first one is a failure since the group's server is setup with the entry somecomp.com MUST_NOPEERMATCH is specified in tls_per_site and consequently the message is not delivered when TLS fails. Is this because they have a self signed certificate and we do not have the CA certificate for their root? In the second set of log entries, I am not certain if the message is delivered over the TLS connection or not. Is there some entry I can search my logs for to find out if any messages are being successfully transmitted over TLS? -- Known Failure -- Aug 22 13:11:43 mail postfix/smtp[7593]: starting TLS engine Aug 22 13:11:44 mail postfix/smtp[7593]: setting up TLS connection to mail.somecomp.com Aug 22 13:11:44 mail postfix/smtp[7593]: SSL_connect:before/connect initialization Aug 22 13:11:44 mail postfix/smtp[7593]: SSL_connect:SSLv2/v3 write client hello A Aug 22 13:11:44 mail postfix/smtp[7593]: SSL_connect:error in SSLv2/v3 read server hello A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:error in SSLv3 read server hello A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:error in SSLv3 read server hello A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:SSLv3 read server hello A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:error in SSLv3 read server certificate A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:error in SSLv3 read server certificate A Aug 22 13:11:45 mail postfix/smtp[7593]: Peer cert verify depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/C N=thistle.somecomp.com/[EMAIL PROTECTED] Aug 22 13:11:45 mail postfix/smtp[7593]: verify error:num=18:self signed certificate Aug 22 13:11:45 mail postfix/smtp[7593]: verify return:0 Aug 22 13:11:45 mail postfix/smtp[7593]: Peer cert verify depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/C N=thistle.somecomp.com/[EMAIL PROTECTED] Aug 22 13:11:45 mail postfix/smtp[7593]: Peer verification: CommonName in certificate does not match: thistle.somecomp.com != mail.somecomp.com Aug 22 13:11:45 mail postfix/smtp[7593]: verify return:1 Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:SSLv3 read server certificate A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:error in SSLv3 read server key exchange A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:error in SSLv3 read server key exchange A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:SSLv3 read server key exchange A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:error in SSLv3 read server certificate request A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:error in SSLv3 read server certificate request A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:SSLv3 read server done A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:SSLv3 write client key exchange A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:SSLv3 write change cipher spec A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:SSLv3 write finished A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:SSLv3 flush data Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:error in SSLv3 read finished A Aug 22 13:11:45 mail postfix/smtp[7593]: SSL_connect:SSLv3 read finished A Aug 22 13:11:45 mail postfix/smtp[7593]: Unverified: subject_CN=thistle.somecomp.com, issuer=thistle.somecomp.com Aug 22 13:11:45 mail postfix/smtp[7593]: TLS connection established to mail.somecomp.com: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Aug 22 13:11:45 mail postfix/smtp[7593]: Peer certficate could not be verified Aug 22 13:11:45 mail postfix/smtp[7593]: 85F4F504254: to=[EMAIL PROTECTED], relay=mail.somecomp.com[xxx.yyy.zzz.aaa], delay=2, status=deferred (TLS-failure: Could not verify certificate) -- Did this work or not? -- Aug 21 22:16:22 mail postfix/smtp[28731]: starting TLS engine Aug 21 22:16:28 mail postfix/smtp[28731]: setting up TLS connection to mail.somecomp2.com Aug 21 22:16:28 mail postfix/smtp[28731]: SSL_connect:before/connect initialization Aug 21 22:16:28 mail postfix/smtp[28731]: SSL_connect:SSLv2/v3 write client hello A Aug 21 22:16:28 mail postfix/smtp[28731]: SSL_connect:error in SSLv2/v3 read server hello A Aug 21 22:16:28 mail postfix/smtp[28731]: SSL_connect:error in SSLv3 read server hello A Aug 21 22:16:28 mail postfix/smtp[28731]: SSL_connect:error in SSLv3 read server hello A Aug 21 22:16:28 mail postfix/smtp[28731]: SSL_connect:SSLv3 read server hello A Aug 21 22:16:28 mail postfix/smtp[28731]:
Re: Questions concerning TLS
Darrell A. Sullivan, II: I am trying to implement TLS on our server for a client requirement. I believe I have the TLS settings correct, but I am not certain about what I am seeing in the logs and I am uncertain as to how to know if a message was delivered using TLS. Is there anything in the message headers that would indicate that it was delivered using TLS? Postfix can add TLS message headers while RECEIVING mail. /etc/postfix/main.cf: smtpd_tls_received_header = yes Postfix currently does not add TLS message headers while delivering mail. Adding such a header would not be a big deal. The code just does not exist because no-one has needed it. I have the below log entries on some outgoing messages. I am certain that the first one is a failure since the group's server is setup with the entry somecomp.com MUST_NOPEERMATCH is specified in tls_per_site and consequently the message is not delivered when TLS fails. Is this because they have a self signed certificate and we do not have the CA certificate for their root? In the second set of log entries, I am not certain if the message is delivered over the TLS connection or not. Is there some entry I can search my logs for to find out if any messages are being successfully transmitted over TLS? This information is not part of routine logs. you can turn up TLS logging, but I would not turn up smtp_tls_loglevel all the way, as that also shows all the protocol negotiation stuff. Wietse
Re: tmda and postfix
Wietse Venema escreveu: Márcio Luciano Donada: Wietse Venema escreveu: M?rcio Luciano Donada: Hi People, I am new in the list and would like to share an idea (I know this is way off) I have a serious problem and has researched in several places and found no answer. The problem is the following, I move an e-mail to test for the user and sends the same e-mail from tmda asking for confirmation that only after I respond to confirmation it sends back another email asking Again the confirmation. Don't shoot Postfix, the messenger. Shoot the software that sends the request for confirmation. Wietse, Thank you for your return. He reaches for me to send confirmation but when I return I have no confirmation message back to talking about the confirmation. Can you present Postfix logs that show: 1) Email from some sender to some TMDA enabled recipient. 2) Challenge from TMDA to the sender. 3) Response from the sender to TMDA. 4) The message from step 1 is delivered to the recipient. If any of the above steps does not happen, can you show the Postfix logs of is happening instead. Wietse Perfect, solution is, in the ~/.tmda/config including RECIPIENT_HEADER = to -- Márcio Luciano Donada mdonada at auroraalimentos dot com dot br Aurora Alimentos - Cooperativa Central Oeste Catarinense Departamento de T.I.
Issue with relay_recipient_maps
Good morning, The following is in my main.cf file: Relay_recipient_maps = hash:/etc/postfix/relay_recipients, Hash:/etc/postfix/relay_recipients_oldmailsystem This is working good. The problem I am having is using a cron job to schedule a rebuild of the relay_recipients. This list contains my Exchange users. I have following the documentation on Postfix's site with no luck. I have a file called update_relay_recipients.sh. This file contains the following: #!/bin/sh cd /etc/postfix ; ./getadsmtp.pl postmap relay_recipients This work if I run it by itself. I have the following setup by running sudo crontab -e 1,30 * * * * cd /etc/postfix ; ./update_relay_recipients.sh This job runs but never works. The relay_recipients file gets updated but the postmap command is never run. Following are my cron.log file entry for this job: Aug 22 11:30:01 mx1 /USR/SBIN/CRON[9722]: (root) CMD (cd /etc/postfix ; ./update_relay_recipients.sh) Any ideas what could be going on? Thanks in advance for any help you may provide. Ray Jette Mestek, Inc. Network Systems Engineer
Using body_checks.
I wrote down the following regular expression, would it work properly?! if /^[ ]*From:(.*)(cmat\.edu\.uy)/ if /^[ ]*Message-ID/ !/^[ ]*Message-ID:(.*)(cmat\.edu\.uy)/ REJECT Message-ID and From incorrect endif endif My idea is reject mail whose From header seems to have an e-mail from my domain, but according to the Message-ID header this message could not be sent from my server. I'm using body_checks because these headers come as part of bounce messages we're receiving (backscatter). Thank you. -- Miguel Da Silva Administrador Junior de Sistemas Unix Centro de Matemática - http://www.cmat.edu.uy Facultad de Ciencias - http://www.fcien.edu.uy Universidad de la República - http://www.rau.edu.uy
Re: Questions concerning TLS
Darrell A. Sullivan, II wrote: I am trying to implement TLS on our server for a client requirement. I believe I have the TLS settings correct, but I am not certain about what I am seeing in the logs and I am uncertain as to how to know if a message was delivered using TLS. Is there anything in the message headers that would indicate that it was delivered using TLS? The receiving system may indicate in a header if the message was received via TLS, but there is no requirement to do so. Some mailers follow RFC3848 or add a comment to indicate use of TLS in the Received header. When *sending* mail, postfix does not add anything to the message indicating use of TLS, and it's unclear how postfix might be able to indicate this in a header. When *receiving* mail, you can request postfix add TLS information to the Received header by setting smtpd_tls_received_header = yes Version 2.5 and newer postfix also add RFC3848 support, indicating with ESTMPS in the Received header if TLS is used. I have the below log entries on some outgoing messages. I am certain that the first one is a failure since the group's server is setup with the entry somecomp.com MUST_NOPEERMATCH is specified in tls_per_site and consequently the message is not delivered when TLS fails. Is this because they have a self signed certificate and we do not have the CA certificate for their root? Are you still using postfix 2.2? I hope not; TLS support was significantly improved in postfix 2.3, and again in 2.4, with further refinements in 2.5. If you're using postfix 2.3 or later, use the newer and more flexible smtp_tls_policy_maps parameter instead. In the second set of log entries, I am not certain if the message is delivered over the TLS connection or not. Is there some entry I can search my logs for to find out if any messages are being successfully transmitted over TLS? TLS logging is hard to read at a high log level. I would suggest starting with smtp_tls_loglevel = 1 And only increase if you need further debugging information. -- Known Failure -- Aug 22 13:11:45 mail postfix/smtp[7593]: Peer verification: CommonName in certificate does not match: thistle.somecomp.com != mail.somecomp.com OK, looks like the hostname doesn't match what is in the certificate. Postfix contacted mail.somecomp.com but the name in the certificate is thistle.somecomp.com. Aug 22 13:11:45 mail postfix/smtp[7593]: Unverified: subject_CN=thistle.somecomp.com, issuer=thistle.somecomp.com I think the mismatched name is the reason this certificate could not be verified. Aug 22 13:11:45 mail postfix/smtp[7593]: TLS connection established to mail.somecomp.com: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) TLS is established. Aug 22 13:11:45 mail postfix/smtp[7593]: Peer certficate could not be verified Aug 22 13:11:45 mail postfix/smtp[7593]: 85F4F504254: to=[EMAIL PROTECTED], relay=mail.somecomp.com[xxx.yyy.zzz.aaa], delay=2, status=deferred (TLS-failure: Could not verify certificate) You told postfix to fail if it couldn't verify the certificate, so it failed. This looks as if you've specified MUST in your tls_per_site table. Using the newer smtp_tls_policy_maps, you probably want to specify a level of encrypt, or you may want to use secure match=thistle.somecomp.com -- Did this work or not? -- /C=US/ST=SC/L=NCHARLESTON/O=somecomp2/CN=Certificate Manager Aug 21 22:16:28 mail postfix/smtp[28731]: verify error:num=19:self signed certificate in certificate chain They use a self-signed certificate. Generally self-signed certificates are fine for mail unless you need to verify the client identity. Aug 21 22:16:28 mail postfix/smtp[28731]: Unverified: subject_CN=mail.somecomp2.com, issuer=Certificate Manager Aug 21 22:16:28 mail postfix/smtp[28731]: TLS connection established to mail.somecomp2.com: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Aug 21 22:16:28 mail postfix/smtp[28731]: Peer certficate could not be verified TLS is established. Postfix can't verify /who/ it's talking to, but it's encrypted. Aug 21 22:18:10 mail postfix/smtp[28731]: 8D05D501C3C: to=[EMAIL PROTECTED], relay=mail.somecomp2.com[xxx.yyy.zzz.aaa], delay=8898, status=sent (250 2.0.0 m7LMVud8002947 Message accepted for delivery) Mail is sent over the established TLS channel. -- Noel Jones
Re: Using body_checks.
Miguel Da Silva - Centro de Matem?tica: I wrote down the following regular expression, would it work properly?! if /^[ ]*From:(.*)(cmat\.edu\.uy)/ if /^[ ]*Message-ID/ !/^[ ]*Message-ID:(.*)(cmat\.edu\.uy)/ REJECT Message-ID and From incorrect endif endif AS DOCUMENTED, the above regexps MUST match the same string. Wietse
Re: Using body_checks.
Miguel Da Silva - Centro de Matemática escribió: I wrote down the following regular expression, would it work properly?! if /^[ ]*From:(.*)(cmat\.edu\.uy)/ if /^[ ]*Message-ID/ !/^[ ]*Message-ID:(.*)(cmat\.edu\.uy)/ REJECT Message-ID and From incorrect endif endif My idea is reject mail whose From header seems to have an e-mail from my domain, but according to the Message-ID header this message could not be sent from my server. I'm using body_checks because these headers come as part of bounce messages we're receiving (backscatter). Thank you. Answering to myself... if /pattern/flags endif Match the input string against the patterns between if and endif, if and only if the same input string also matches /pattern/. The if..endif can nest. Taken from header_checks(5) manual page. So, I will not find an input string with From and Message-ID header at the same time. :( Greetings. -- Miguel Da Silva Administrador Junior de Sistemas Unix Centro de Matemática - http://www.cmat.edu.uy Facultad de Ciencias - http://www.fcien.edu.uy Universidad de la República - http://www.rau.edu.uy
Backscatter problem?
Dear All, I have found the below in my Postfix logs. I believe I have a backscatter problem, which seems to have gotten me in some SPAM black lists out there: [EMAIL PROTECTED]:/home/root# cat /var/log/maillog* | grep 54EF0453B Aug 18 18:26:19 Natsumi postfix/smtpd[12950]: 54EF0453B: client= c-68-44-19-67.hsd1.nj.comcast.net[68.44.19.67] Aug 18 18:26:20 Natsumi postfix/cleanup[12954]: 54EF0453B: [EMAIL PROTECTED] Aug 18 18:26:20 Natsumi postfix/qmgr[2661]: 54EF0453B: from= [EMAIL PROTECTED], size=1009, nrcpt=5 (queue active) Aug 18 18:26:21 Natsumi postfix/local[12959]: 54EF0453B: to= [EMAIL PROTECTED], relay=local, delay=2.3, delays=1.8/0.42/0/0.02, dsn=2.0.0, status=sent (delivered to maildir) Aug 18 18:26:21 Natsumi postfix/local[12958]: 54EF0453B: to= [EMAIL PROTECTED], relay=local, delay=2.3, delays=1.8/0.27/0/0.2, dsn=5.2.0, status=bounced (maildir delivery failed: create maildir file //Maildir/tmp/1219094781.P12958.Natsumi: Permission denied) Aug 18 18:26:21 Natsumi postfix/local[12958]: 54EF0453B: to= [EMAIL PROTECTED], relay=local, delay=2.3, delays=1.8/0.47/0/0.01, dsn=5.2.0, status=bounced (maildir delivery failed: create maildir file /var/spool/uucppublic/Maildir/tmp/1219094781.P12958.Natsumi: Permission denied) Aug 18 18:26:21 Natsumi postfix/local[12959]: 54EF0453B: to= [EMAIL PROTECTED], relay=local, delay=2.3, delays=1.8/0.45/0/0.03, dsn=2.0.0, status=sent (delivered to maildir) Aug 18 18:26:21 Natsumi postfix/local[12955]: 54EF0453B: to= [EMAIL PROTECTED], relay=local, delay=2.3, delays=1.8/0.07/0/0.45, dsn=2.0.0, status=sent (delivered to maildir) Aug 18 18:26:21 Natsumi postfix/bounce[12960]: 54EF0453B: sender non-delivery notification: 6B26F4544 Aug 18 18:26:21 Natsumi postfix/qmgr[2661]: 54EF0453B: removed If my understanding is correct, I am receiving SPAM with a forged source address. This SPAM is accepted by my valid mailboxes ( [EMAIL PROTECTED] above), and *bounced* (not not rejected!) by my invalid mailboxes (mail, uucp, ... above) This bounce notification is then sent to the forged source address: [EMAIL PROTECTED]:/home/root# cat /var/log/maillog* | grep 6B26F4544 Aug 18 18:26:21 Natsumi postfix/cleanup[12962]: 6B26F4544: message-id= [EMAIL PROTECTED] Aug 18 18:26:21 Natsumi postfix/qmgr[2661]: 6B26F4544: from=, size=3502, nrcpt=1 (queue active) Aug 18 18:26:21 Natsumi postfix/bounce[12960]: 54EF0453B: sender non-delivery notification: 6B26F4544 Aug 18 18:26:25 Natsumi postfix/smtp[12944]: 6B26F4544: to= [EMAIL PROTECTED], relay= networkworld.com.s6a1.psmtp.com[64.18.5.10]:25, delay=4.1, delays=0.09/0/3.4/0.58, dsn=5.0.0, status=bounced (host networkworld.com.s6a1.psmtp.com[64.18.5.10] said: 550 No such user - psmtp (in reply to RCPT TO command)) Aug 18 18:26:26 Natsumi postfix/qmgr[2661]: 6B26F4544: removed I am quite worried about this. Could anyone kindly help me figure out which postfix 2.5.1 configuration parameters can I use to prevent this type of abuse? Thank you very much in advance, Gaston DASSIEU-BLANCHET
Re: Using body_checks.
Miguel Da Silva - Centro de Matemática wrote: I wrote down the following regular expression, would it work properly?! if /^[ ]*From:(.*)(cmat\.edu\.uy)/ if /^[ ]*Message-ID/ !/^[ ]*Message-ID:(.*)(cmat\.edu\.uy)/ REJECT Message-ID and From incorrect endif endif My idea is reject mail whose From header seems to have an e-mail from my domain, but according to the Message-ID header this message could not be sent from my server. No. If you need to take decisions based on the contents of multiple lines, use a content filter. This is explained in body_checks(5), which you can read on your system (man body_checks) or on the web: http://www.postfix.org/header_checks.5.html In particular, read the part that says: cite ... Many people overlook the main limitations of header and body_checks rules. o These rules operate on one logical message header or one body line at a time. A decision made for one line is not carried over to the next line. o If text in the message body is encoded (RFC 2045) then the rules need to be specified for the encoded form. o Likewise, when message headers are encoded (RFC 2047) then the rules need to be specified for the encoded form. ... /cite I'm using body_checks because these headers come as part of bounce messages we're receiving (backscatter). Thank you.
Re: Backscatter problem?
Gaston Dassieu Blanchet wrote: Dear All, I have found the below in my Postfix logs. I believe I have a backscatter problem, which seems to have gotten me in some SPAM black lists out there: [EMAIL PROTECTED]:/home/root# cat /var/log/maillog* | grep 54EF0453B Aug 18 18:26:19 Natsumi postfix/smtpd[12950]: 54EF0453B: client= c-68-44-19-67.hsd1.nj.comcast.net[68.44.19.67] Aug 18 18:26:20 Natsumi postfix/cleanup[12954]: 54EF0453B: [EMAIL PROTECTED] Aug 18 18:26:20 Natsumi postfix/qmgr[2661]: 54EF0453B: from= [EMAIL PROTECTED], size=1009, nrcpt=5 (queue active) Aug 18 18:26:21 Natsumi postfix/local[12959]: 54EF0453B: to= [EMAIL PROTECTED], relay=local, delay=2.3, delays=1.8/0.42/0/0.02, dsn=2.0.0, status=sent (delivered to maildir) Aug 18 18:26:21 Natsumi postfix/local[12958]: 54EF0453B: to= [EMAIL PROTECTED], relay=local, delay=2.3, delays=1.8/0.27/0/0.2, dsn=5.2.0, status=bounced (maildir delivery failed: create maildir file //Maildir/tmp/1219094781.P12958.Natsumi: Permission denied) Aug 18 18:26:21 Natsumi postfix/local[12958]: 54EF0453B: to= [EMAIL PROTECTED], relay=local, delay=2.3, delays=1.8/0.47/0/0.01, dsn=5.2.0, status=bounced (maildir delivery failed: create maildir file /var/spool/uucppublic/Maildir/tmp/1219094781.P12958.Natsumi: Permission denied) Aug 18 18:26:21 Natsumi postfix/local[12959]: 54EF0453B: to= [EMAIL PROTECTED], relay=local, delay=2.3, delays=1.8/0.45/0/0.03, dsn=2.0.0, status=sent (delivered to maildir) Aug 18 18:26:21 Natsumi postfix/local[12955]: 54EF0453B: to= [EMAIL PROTECTED], relay=local, delay=2.3, delays=1.8/0.07/0/0.45, dsn=2.0.0, status=sent (delivered to maildir) Aug 18 18:26:21 Natsumi postfix/bounce[12960]: 54EF0453B: sender non-delivery notification: 6B26F4544 Aug 18 18:26:21 Natsumi postfix/qmgr[2661]: 54EF0453B: removed If my understanding is correct, I am receiving SPAM with a forged source address. This SPAM is accepted by my valid mailboxes ( [EMAIL PROTECTED] above), and *bounced* (not not rejected!) by my invalid mailboxes (mail, uucp, ... above) This bounce notification is then sent to the forged source address: [EMAIL PROTECTED]:/home/root# cat /var/log/maillog* | grep 6B26F4544 Aug 18 18:26:21 Natsumi postfix/cleanup[12962]: 6B26F4544: message-id= [EMAIL PROTECTED] Aug 18 18:26:21 Natsumi postfix/qmgr[2661]: 6B26F4544: from=, size=3502, nrcpt=1 (queue active) Aug 18 18:26:21 Natsumi postfix/bounce[12960]: 54EF0453B: sender non-delivery notification: 6B26F4544 Aug 18 18:26:25 Natsumi postfix/smtp[12944]: 6B26F4544: to= [EMAIL PROTECTED], relay= networkworld.com.s6a1.psmtp.com[64.18.5.10]:25, delay=4.1, delays=0.09/0/3.4/0.58, dsn=5.0.0, status=bounced (host networkworld.com.s6a1.psmtp.com[64.18.5.10] said: 550 No such user - psmtp (in reply to RCPT TO command)) Aug 18 18:26:26 Natsumi postfix/qmgr[2661]: 6B26F4544: removed I am quite worried about this. Could anyone kindly help me figure out which postfix 2.5.1 configuration parameters can I use to prevent this type of abuse? Thank you very much in advance, spammer is targetting well-known unix accounts. use check_recipient_access to reject mail sent to mail, uucp, apache, www, ftp, ... (all unix accounts that are not supposed to receive mail). PS. be careful with accounts that are used to run cron jobs. in case of errors, cron will send mail on bahalf of these users. if such mail is sent to the mail server, it should not be rejected.
Re: Using body_checks.
mouss wrote: Miguel Da Silva - Centro de Matemática wrote: I wrote down the following regular expression, would it work properly?! if /^[ ]*From:(.*)(cmat\.edu\.uy)/ if /^[ ]*Message-ID/ !/^[ ]*Message-ID:(.*)(cmat\.edu\.uy)/ REJECT Message-ID and From incorrect endif endif My idea is reject mail whose From header seems to have an e-mail from my domain, but according to the Message-ID header this message could not be sent from my server. No. If you need to take decisions based on the contents of multiple lines, use a content filter. This is explained in body_checks(5), which you can read on your system (man body_checks) or on the web: http://www.postfix.org/header_checks.5.html In particular, read the part that says: cite ... Many people overlook the main limitations of header and body_checks rules. o These rules operate on one logical message header or one body line at a time. A decision made for one line is not carried over to the next line. o If text in the message body is encoded (RFC 2045) then the rules need to be specified for the encoded form. o Likewise, when message headers are encoded (RFC 2047) then the rules need to be specified for the encoded form. ... /cite Some suggestions on how to stop most backscatter using postfix are found in http://www.postfix.org/BACKSCATTER_README.html For more in-depth checks, one must use a content_filter. Spamassassin's vbounce ruleset does a pretty good job of catching these. -- Noel Jones
RE: Questions concerning TLS
Thanks Noel, I double checked and even reran postmap on the tls_per_site file and did a postfix stop postfix start just to make sure that MUST_NOPEERMATCH was specified and everything was getting reset, but it is still giving me a result of (TLS-failure: Could not verify certificate) when I attempt to send to the destination e-mail address. -Original Message- From: Noel Jones [mailto:[EMAIL PROTECTED] Sent: Friday, August 22, 2008 12:02 PM To: Darrell A. Sullivan, II; postfix-users@postfix.org Subject: Re: Questions concerning TLS Darrell A. Sullivan, II wrote: I am trying to implement TLS on our server for a client requirement. I believe I have the TLS settings correct, but I am not certain about what I am seeing in the logs and I am uncertain as to how to know if a message was delivered using TLS. Is there anything in the message headers that would indicate that it was delivered using TLS? The receiving system may indicate in a header if the message was received via TLS, but there is no requirement to do so. Some mailers follow RFC3848 or add a comment to indicate use of TLS in the Received header. When *sending* mail, postfix does not add anything to the message indicating use of TLS, and it's unclear how postfix might be able to indicate this in a header. When *receiving* mail, you can request postfix add TLS information to the Received header by setting smtpd_tls_received_header = yes Version 2.5 and newer postfix also add RFC3848 support, indicating with ESTMPS in the Received header if TLS is used. I have the below log entries on some outgoing messages. I am certain that the first one is a failure since the group's server is setup with the entry somecomp.com MUST_NOPEERMATCH is specified in tls_per_site and consequently the message is not delivered when TLS fails. Is this because they have a self signed certificate and we do not have the CA certificate for their root? Are you still using postfix 2.2? I hope not; TLS support was significantly improved in postfix 2.3, and again in 2.4, with further refinements in 2.5. If you're using postfix 2.3 or later, use the newer and more flexible smtp_tls_policy_maps parameter instead. In the second set of log entries, I am not certain if the message is delivered over the TLS connection or not. Is there some entry I can search my logs for to find out if any messages are being successfully transmitted over TLS? TLS logging is hard to read at a high log level. I would suggest starting with smtp_tls_loglevel = 1 And only increase if you need further debugging information. -- Known Failure -- Aug 22 13:11:45 mail postfix/smtp[7593]: Peer verification: CommonName in certificate does not match: thistle.somecomp.com != mail.somecomp.com OK, looks like the hostname doesn't match what is in the certificate. Postfix contacted mail.somecomp.com but the name in the certificate is thistle.somecomp.com. Aug 22 13:11:45 mail postfix/smtp[7593]: Unverified: subject_CN=thistle.somecomp.com, issuer=thistle.somecomp.com I think the mismatched name is the reason this certificate could not be verified. Aug 22 13:11:45 mail postfix/smtp[7593]: TLS connection established to mail.somecomp.com: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) TLS is established. Aug 22 13:11:45 mail postfix/smtp[7593]: Peer certficate could not be verified Aug 22 13:11:45 mail postfix/smtp[7593]: 85F4F504254: to=[EMAIL PROTECTED], relay=mail.somecomp.com[xxx.yyy.zzz.aaa], delay=2, status=deferred (TLS-failure: Could not verify certificate) You told postfix to fail if it couldn't verify the certificate, so it failed. This looks as if you've specified MUST in your tls_per_site table. Using the newer smtp_tls_policy_maps, you probably want to specify a level of encrypt, or you may want to use secure match=thistle.somecomp.com -- Did this work or not? -- /C=US/ST=SC/L=NCHARLESTON/O=somecomp2/CN=Certificate Manager Aug 21 22:16:28 mail postfix/smtp[28731]: verify error:num=19:self signed certificate in certificate chain They use a self-signed certificate. Generally self-signed certificates are fine for mail unless you need to verify the client identity. Aug 21 22:16:28 mail postfix/smtp[28731]: Unverified: subject_CN=mail.somecomp2.com, issuer=Certificate Manager Aug 21 22:16:28 mail postfix/smtp[28731]: TLS connection established to mail.somecomp2.com: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Aug 21 22:16:28 mail postfix/smtp[28731]: Peer certficate could not be verified TLS is established. Postfix can't verify /who/ it's talking to, but it's encrypted. Aug 21 22:18:10 mail postfix/smtp[28731]: 8D05D501C3C: to=[EMAIL PROTECTED], relay=mail.somecomp2.com[xxx.yyy.zzz.aaa], delay=8898, status=sent (250 2.0.0 m7LMVud8002947 Message accepted for delivery) Mail is sent over the established TLS channel. -- Noel Jones
Re: Backscatter problem?
Gaston Dassieu Blanchet wrote: Dear All, I have found the below in my Postfix logs. I believe I have a backscatter problem, which seems to have gotten me in some SPAM black lists out there: [EMAIL PROTECTED]:/home/root# cat /var/log/maillog* | grep 54EF0453B Aug 18 18:26:19 Natsumi postfix/smtpd[12950]: 54EF0453B: client=c-68-44-19-67.hsd1.nj.comcast.net http://c-68-44-19-67.hsd1.nj.comcast.net[68.44.19.67 http://68.44.19.67] Aug 18 18:26:20 Natsumi postfix/cleanup[12954]: 54EF0453B: [EMAIL PROTECTED] Aug 18 18:26:20 Natsumi postfix/qmgr[2661]: 54EF0453B: from=[EMAIL PROTECTED] mailto:[EMAIL PROTECTED], size=1009, nrcpt=5 (queue active) Aug 18 18:26:21 Natsumi postfix/local[12958]: 54EF0453B: to=[EMAIL PROTECTED] mailto:[EMAIL PROTECTED], relay=local, delay=2.3, delays=1.8/0.27/0/0.2, dsn=5.2.0, status=bounced (maildir delivery failed: create maildir file //Maildir/tmp/1219094781.P12958.Natsumi: Permission denied) Aug 18 18:26:21 Natsumi postfix/local[12958]: 54EF0453B: to=[EMAIL PROTECTED] mailto:[EMAIL PROTECTED], relay=local, delay=2.3, delays=1.8/0.47/0/0.01, dsn=5.2.0, status=bounced (maildir delivery failed: create maildir file /var/spool/uucppublic/Maildir/tmp/1219094781.P12958.Natsumi: Permission denied) Aug 18 18:26:21 Natsumi postfix/bounce[12960]: 54EF0453B: sender non-delivery notification: 6B26F4544 Aug 18 18:26:21 Natsumi postfix/qmgr[2661]: 54EF0453B: removed If my understanding is correct, I am receiving SPAM with a forged source address. This SPAM is accepted by my valid mailboxes ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED] above), and *bounced* (not not rejected!) by my invalid mailboxes (mail, uucp, ... above) I am quite worried about this. Could anyone kindly help me figure out which postfix 2.5.1 configuration parameters can I use to prevent this type of abuse? These are default users that are for services. They are required, however, do not have to receive mail as mouss has pointed out. Without 'postconf -n', I can only give some general advice. If you are not using RBLs, then please start. Better: Using a scoring system like postfwd or policyd-weight (development currently paused). Brian
Re: Questions concerning TLS
Darrell A. Sullivan, II wrote: Thanks Noel, I double checked and even reran postmap on the tls_per_site file and did a postfix stop postfix start just to make sure that MUST_NOPEERMATCH was specified and everything was getting reset, but it is still giving me a result of (TLS-failure: Could not verify certificate) when I attempt to send to the destination e-mail address. Please don't top-post. I suggest using the newer smtp_tls_policy_maps parameter instead. If you are using postfix 2.2 or earlier, I strongly suggest upgrading. http://www.postfix.org/TLS_README.html#client_tls_policy -- Noel Jones
RE: Issue with relay_recipient_maps
Thanks for the quick reply. That solved my problem. Thanks again. Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Duane Hill Sent: Friday, August 22, 2008 11:52 AM To: postfix-users@postfix.org Subject: Re: Issue with relay_recipient_maps On Fri, 22 Aug 2008, Raymond Jette wrote: Good morning, The following is in my main.cf file: Relay_recipient_maps = hash:/etc/postfix/relay_recipients, Hash:/etc/postfix/relay_recipients_oldmailsystem This is working good. The problem I am having is using a cron job to schedule a rebuild of the relay_recipients. This list contains my Exchange users. I have following the documentation on Postfix?s site with no luck. I have a file called update_relay_recipients.sh. This file contains the following: #!/bin/sh cd /etc/postfix ; ./getadsmtp.pl postmap relay_recipients This work if I run it by itself. I have the following setup by running sudo crontab ?e 1,30 * * * * cd /etc/postfix ; ./update_relay_recipients.sh This job runs but never works. The relay_recipients file gets updated but the postmap command is never run. Following are my cron.log file entry for this job: Aug 22 11:30:01 mx1 /USR/SBIN/CRON[9722]: (root) CMD (cd /etc/postfix ; ./update_relay_recipients.sh) Any ideas what could be going on? Thanks in advance for any help you may provide. It would be my guess your crontab can not find 'postmap' because it isn't in environment's PATH. On FreeBSD, 'man 5 crontab' shows PATH is set to /usr/bin and /bin. In FreeBSD, postmap lives in /usr/local/sbin if installed via the ports tree. Therefore, the script would not be able to find 'postmap'. However, if I were to add to the top of the crontab: PATH=/usr/bin:/bin:/usr/local/sbin the script would be able to find 'postmap'. Otherwise, in your script, if you use an absolute path to where 'postmap' lives, it should work. -d
Re: Questions concerning TLS
On Fri, 22 Aug 2008 10:07:20 -0400 (EDT) [EMAIL PROTECTED] (Wietse Venema) wrote: Postfix can add TLS message headers while RECEIVING mail. /etc/postfix/main.cf: smtpd_tls_received_header = yes Postfix currently does not add TLS message headers while delivering mail. Adding such a header would not be a big deal. The code just does not exist because no-one has needed it. Personally, I would be in favor of it, if it really is not a big deal nor going to take up too much of your time. -- Jerry [EMAIL PROTECTED] signature.asc Description: PGP signature
Enable SMTP Authentication
Hello. I have Ubuntu Server 7.04 acting as a mail server with postfix 2.3.8. Smtp authentication is currently not configured so users have to use webmail when they are outside the lan. I've been googling around for smtp athentication and found some info but it uses Cyrus which (as i heard) is quite difficult to configure. I've also found other tutorials that use Dovecot (with myslq db) which seems to be a lot easier to configure. The thing is, users are authenticated using system credentials (to create a new mail account i have to add a new user to the system, ...is this called ldap??). So, my question is, could i install dovecot and sasl using this kind of user authentication?. Any help is greatly appreciated.
Re: Enable SMTP Authentication
On Fri, 22 Aug 2008 20:27:57 +0200 mouss [EMAIL PROTECTED] wrote: ... once dovecot is configured, read http://www.postfix.org/SASL_README.html to setup postfix. Make sure your postfix was built with dovecot (sasl) support (so don't use an ancient postfix). I don't recall if the Feisty Postfix was built with support for Dovecot SASL or not. Postfix 2.5.4 is available in the community supported feisty-backports repository if you need it. Scott K
Re: How to get that working? Use a plociy-daemon?
Max Zimmermann: Hey there, I hope I'm right asking you this, and hope I can explain my problem correctly. I'm not receiving to many spam mails on my server. With all postfix-internal sender- and helo restrictions and some RBLs enabled, spam for me has come down to only a few mails that get through each day. So far so good. The problem I have now is that one account that recently also sends and receives emails via my server, from time to time receives mail from people that run either RFC-incompliant (or incorrectly configured) MTA's or servers. Their mails are being rejected correctly, of course. But for one domain I would appreciate not having those false-positives, and not losing these emails. To avoid RFC compliance checks for domain example.com, put them after a recipient access table. For example: /etc/postfix/main.cf: smtpd_recipient_restrictions = reject_unlisted_recipient permit_mynetworks ... reject_unauth_destination check_recipient_access hash:/etc/postfix/recipient_access [RFC compliance checks here] ... /etc/postfix/recipient_access example.com OK So what I had in mind now is, that those emails don't get rejected, but delivered to a special spam-folder in the users maildir. Unformtunately, Postfix has no built-in feature to label mail. Wietse
Re: Small Enhancement for the Policy Server Protocol
In message [EMAIL PROTECTED], [EMAIL PROTECTED] (Wietse Venema) wrote: I mean isn't Postfix making this determination (relay authorized / unauthorized) internally itself already anyway? No, the determination is made in smtpd_recipient_restrictions. I won't quibble senamtics. _Something_ implements/interpolates the smtpd_recipient_restrictions into a useful result. That something is Postfix. Can you please save me a bit of time and give me one hint to get me started however? In which data structure (and in which field) does Postfix stash its own answer to the question Is the current client relay authorized? There is no such field. smtpd_recipient_restrictions decides if recipient is accepted or rejected. Postfix does not know if it was rejected because of blacklisting or because of lack of permission. Ah! OK. *Now* you have said something that does make me grok the problem a bit better. Yes, you're right. Postfix doesn't actually have the specific bit of information I want/need in my policy server (despite the fact that I had really hoped that it did) and thus it seems I have no choice but implement a separate sort of computation in the policy server that will give me something which approximates an incoming/outgoing bit... at least well enough for my specific practical purposes. Anyway, thanks for bearing with me long enough for me to actually understand the dilemma.
Re: Small Enhancement for the Policy Server Protocol
In message [EMAIL PROTECTED], Noel Jones [EMAIL PROTECTED] wrote: Ronald F. Guilmette wrote: Postfix doesn't actually have the specific bit of information I want/need in my policy server (despite the fact that I had really hoped that it did) and thus it When a policy service is called, postfix doesn't know if a specific client has relay access. YOU define who has relay access in smtpd_recipient_restrictions, which may have complex nested rules, and may not have been evaluated yet. Right. I _did_ grok all that already, based on Wietse's last post. But thanks for reiterating. It's not unreasonable to add a mynetworks_client=[yes,no] to the policy protocol. Perhaps, but it does seem rather entirely less useful to me now than it did earlier. Hack up a patch (with a terse documentation diff too) and submit it for comment. I think I'm going to take a pass on that. But thanks. It's easy enough to just pass a copy of $mynetworks to an external policy server, e.g. via the command line argv.
Re: Small Enhancement for the Policy Server Protocol
Ronald F. Guilmette wrote: It's easy enough to just pass a copy of $mynetworks to an external policy server, e.g. via the command line argv. #main.cf mynetworks = /path/to/file or mynetworks = cidr:/path/to/file (the file format is slightly different for each of the above examples) use the same file in your policy service. http://www.postfix.org/postconf.5.html#mynetworks -- Noel Jones
Selective *non*-enforcement of FQDN rules?
I've been looking around to see how I can deal with a particular site that doesn't report a FQDN in the HELO/EHLO line. I have smtpd_recipient_restrictions containing: reject_non_fqdn_sender reject_non_fqdn_recipient reject_non_fqdn_hostname to help with SPAM issues. I want these enforced for everyone EXCEPT one site (heck, one IP) that needs to talk to me (but I've been unable to get their admin to fix their broken configuration). Is this possible or am I just missing something really obvious? Any pointers would be greatly appreciated. Thanks! -Michael
Re: Selective *non*-enforcement of FQDN rules?
Michael G. Reed: I've been looking around to see how I can deal with a particular site that doesn't report a FQDN in the HELO/EHLO line. I have smtpd_recipient_restrictions containing: reject_non_fqdn_sender reject_non_fqdn_recipient reject_non_fqdn_hostname to help with SPAM issues. I want these enforced for everyone EXCEPT one site (heck, one IP) that needs to talk to me (but I've been unable to get their admin to fix their broken configuration). Is this possible or am I just missing something really obvious? Any pointers would be greatly appreciated. Thanks! Perhaps: /etc/postfix/main.cf: smtpd_recipient_restrictions = ... check_client_access pcre:/etc/postfix/client_pcre ... /etc/postfix/client_pcre: 192.168.0.1/32 dunno 0.0.0.0/0 reject_non_fqdn_sender, reject_non_fqdn_recipient, ... ::/0reject_non_fqdn_sender, reject_non_fqdn_recipient, ... Not intuitive, but effective. man 5 access man 5 cidr_table Wietse
Re: Selective *non*-enforcement of FQDN rules?
Worked like a champ. (for anyone else interested, put OK for dunno below and you're good to go :). Thanks! -Michael On Fri, 22 Aug 2008, Wietse Venema wrote: | Wietse Venema: | Michael G. Reed: |I've been looking around to see how I can deal with a | particular site that doesn't report a FQDN in the HELO/EHLO line. I | have smtpd_recipient_restrictions containing: | | reject_non_fqdn_sender | reject_non_fqdn_recipient | reject_non_fqdn_hostname | | to help with SPAM issues. I want these enforced for everyone EXCEPT | one site (heck, one IP) that needs to talk to me (but I've been unable | to get their admin to fix their broken configuration). Is this | possible or am I just missing something really obvious? Any pointers | would be greatly appreciated. Thanks! | | Sorry, I used PCRE instead of CIDR. Corrected version follows. | | Wietse | | Perhaps: | | /etc/postfix/main.cf: | smtpd_recipient_restrictions = | ... | check_client_access cidr:/etc/postfix/client_cidr | ... | | /etc/postfix/client_cidr: | 192.168.0.1/32 dunno | 0.0.0.0/0reject_non_fqdn_sender, reject_non_fqdn_recipient, ... | ::/0 reject_non_fqdn_sender, reject_non_fqdn_recipient, ... | | Not intuitive, but effective. | | man 5 access | man 5 cidr_table | | Wietse
Re: Selective *non*-enforcement of FQDN rules?
Michael G. Reed: Worked like a champ. (for anyone else interested, put OK for dunno below and you're good to go :). Thanks! DO NOT PUT OK THERE!!! YOU MAY BECOME AN OPEN RELAY!! Wietse On Fri, 22 Aug 2008, Wietse Venema wrote: | Wietse Venema: | Michael G. Reed: | I've been looking around to see how I can deal with a | particular site that doesn't report a FQDN in the HELO/EHLO line. I | have smtpd_recipient_restrictions containing: | | reject_non_fqdn_sender | reject_non_fqdn_recipient | reject_non_fqdn_hostname | | to help with SPAM issues. I want these enforced for everyone EXCEPT | one site (heck, one IP) that needs to talk to me (but I've been unable | to get their admin to fix their broken configuration). Is this | possible or am I just missing something really obvious? Any pointers | would be greatly appreciated. Thanks! | | Sorry, I used PCRE instead of CIDR. Corrected version follows. | |Wietse | | Perhaps: | | /etc/postfix/main.cf: | smtpd_recipient_restrictions = |... |check_client_access cidr:/etc/postfix/client_cidr |... | | /etc/postfix/client_cidr: | 192.168.0.1/32 dunno | 0.0.0.0/0 reject_non_fqdn_sender, reject_non_fqdn_recipient, ... | ::/0 reject_non_fqdn_sender, reject_non_fqdn_recipient, ... | | Not intuitive, but effective. | | man 5 access | man 5 cidr_table | |Wietse
Re: Selective *non*-enforcement of FQDN rules?
On Fri, 22 Aug 2008, Michael G. Reed wrote: Worked like a champ. (for anyone else interested, put OK for dunno below and you're good to go :). Thanks! Take CAREFUL consideration in using OK. It can open your server up like a can of worms. Telling Postfix OK will bypass all further restrictions in whatever smtpd_*_restrictions section you have it listed in. According to 'man 5 access', DUNNO will pretend the lookup key was not found and continue on with the next restriction. On Fri, 22 Aug 2008, Wietse Venema wrote: | Wietse Venema: | Michael G. Reed: | I've been looking around to see how I can deal with a | particular site that doesn't report a FQDN in the HELO/EHLO line. I | have smtpd_recipient_restrictions containing: | | reject_non_fqdn_sender | reject_non_fqdn_recipient | reject_non_fqdn_hostname | | to help with SPAM issues. I want these enforced for everyone EXCEPT | one site (heck, one IP) that needs to talk to me (but I've been unable | to get their admin to fix their broken configuration). Is this | possible or am I just missing something really obvious? Any pointers | would be greatly appreciated. Thanks! | | Sorry, I used PCRE instead of CIDR. Corrected version follows. | | Wietse | | Perhaps: | | /etc/postfix/main.cf: | smtpd_recipient_restrictions = | ... | check_client_access cidr:/etc/postfix/client_cidr | ... | | /etc/postfix/client_cidr: | 192.168.0.1/32dunno | 0.0.0.0/0 reject_non_fqdn_sender, reject_non_fqdn_recipient, ... | ::/0 reject_non_fqdn_sender, reject_non_fqdn_recipient, ... | | Not intuitive, but effective. | | man 5 access | man 5 cidr_table | | Wietse -d
Re: Selective *non*-enforcement of FQDN rules?
Ah! My bad (really, really bad :). I did a quick search of the man pages and didn't look too carefully (darn case sensitivity on searching). Thank you (and Wietse, I saw your message too and immediatelly slammed down my server to fix it) for catching that before it blew up! -Michael On Sat, 23 Aug 2008, Duane Hill wrote: | On Fri, 22 Aug 2008, Michael G. Reed wrote: | | Worked like a champ. (for anyone else interested, put OK | for dunno below and you're good to go :). Thanks! | | Take CAREFUL consideration in using OK. It can open your server up like | a can of worms. Telling Postfix OK will bypass all further restrictions in | whatever smtpd_*_restrictions section you have it listed in. | | According to 'man 5 access', DUNNO will pretend the lookup key was not | found and continue on with the next restriction. | | On Fri, 22 Aug 2008, Wietse Venema wrote: | | Wietse Venema: | | Michael G. Reed: | | I've been looking around to see how I can deal with a | | particular site that doesn't report a FQDN in the HELO/EHLO line. I | | have smtpd_recipient_restrictions containing: | | | | reject_non_fqdn_sender | | reject_non_fqdn_recipient | | reject_non_fqdn_hostname | | | | to help with SPAM issues. I want these enforced for everyone EXCEPT | | one site (heck, one IP) that needs to talk to me (but I've been unable | | to get their admin to fix their broken configuration). Is this | | possible or am I just missing something really obvious? Any pointers | | would be greatly appreciated. Thanks! | | | | Sorry, I used PCRE instead of CIDR. Corrected version follows. | | | | Wietse | | | | Perhaps: | | | | /etc/postfix/main.cf: | | smtpd_recipient_restrictions = | | ... | | check_client_access cidr:/etc/postfix/client_cidr | | ... | | | | /etc/postfix/client_cidr: | | 192.168.0.1/32 dunno | | 0.0.0.0/0 reject_non_fqdn_sender, reject_non_fqdn_recipient, ... | | ::/0reject_non_fqdn_sender, reject_non_fqdn_recipient, ... | | | | Not intuitive, but effective. | | | | man 5 access | | man 5 cidr_table | | | | Wietse
