Re: how to restrict mail to only one recipient?
postfix rocks!! :-)
working perfectly...
thanks mouss
regards,
Israel.
On Sun, Apr 18, 2010 at 12:42 AM, mouss wrote:
> Israel Garcia a écrit :
>> Hi
>> I have some apps on a debian server which use to send mail using
>> localhost on the same server and I want allow only email sent to this
>> address u...@domain and reject all other. This is my main.cf
>>
>> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
>> biff = no
>> append_dot_mydomain = no
>> readme_directory = no
>>
>> # TLS parameters
>> smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
>> smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
>> smtpd_use_tls=yes
>> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
>> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
>>
>> myhostname = myserver.mydomain
>> alias_maps = hash:/etc/aliases
>> alias_database = hash:/etc/aliases
>> myorigin = /etc/mailname
>> mydestination = myserver.mydomain, localhost.speedyrails.ca, , localhost
>> smtpd_recipient_restrictions =
>> check_recipient_access hash:/etc/postfix/recipients,
>> check_relay_domains,
>> reject
>>
>> relayhost = [lbsmtp]
>> smtp_host_lookup = dns,native
>> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
>> mailbox_size_limit = 0
>> recipient_delimiter = +
>> inet_interfaces = localhost
>> mailbox_command =
>> default_transport = smtp
>> relay_transport = smtp
>> smtp_host_lookup=dns,native
>> inet_protocols = ipv4
>>
>> /etc/postfix/recipient file:
>>
>> u...@domain OK
>> \...@\* REJECT
>
> the last line is useless.
>
>>
>> So, if I test sending mail using mail command or mutt rules does not
>> work, but, if I use telnet or nc to connect to localhost on 25/tcp
>> port rule works. Simple question, WHY?
>
> because smtpd_* parameters apply to mail received via SMTP.
>
>>
>> How can I restrict my server to send mail TO u...@domain?
>>
>
> There are many ways...
>
> [transports]
> instead of using smtpd restrictions, you can use transport_maps:
>
> u...@domain smtp:
> * error:recipient address not allowed
>
> (note that '*' only works for transport_maps. don't use it in access maps).
>
> [smtpd restrictions via a content filter]
> you can force mail submitted via the sendmail (pickup) interface to go
> through smtpd by adding
> -o content_filter=smtp:[127.0.0.1]:25
>
> under the "pickup" service in master.cf. However:
>
> - if you do so, you must not use the sendmail command after content
> filtering. otherwise, you'll get an infinite loop.
>
> - mail that will be rejected will cause a bounce. you need to handle
> this. Instead of "reject", you could use HOLD to put mail on hold (and
> remove it manually using the postsuper command), or you can
>
>> NOTES:
>> This server only accept mails from localhost
>> This server send mails to a load balancer [lbsmtp]
>>
>> thanks in advance
>>
>
>
--
Regards;
Israel Garcia
Re: recipient_delimiter is not set
On 17-Apr-2010, at 22:09, Jim Carter wrote: > > I have recipient_delimiter = + in main.cf, but postconf -d reports that > the variable is empty. postconf -d will *always* report that as empty. Have you looked at the man page for postconf -d to see what it does? (H INT: It's not what you think) -- 'Nothing works against magic. Except stronger magic. And then the only thing that beats stronger magic is even stronger magic. And the next thing you know...' 'Phooey?' --Sourcery
Question about bounce related spam
Hi, I am new to postfix, so sorry for any inconvenience by questions, which may have been discussed ealready. I did google for my problem first, though. I recently migrated an internet server including mail services for a small group of users from linux to Mac OSX server (not my idea). On linux I used to run the MTA with exim, so I have some familiarity with MTA in general, but not with postfix. The postfix on the Mac OSX server is so far more or less what you can do with the server admin (meaning Apple defaults, basically). Here comes the question/problem: I noticed a considerable number of wicked spam, which seems to work like this: It puts a valid existing local user not only in the To: but also in the From: header. The spam gets filtered alright by spamassassin, and then it bounces, but it doesn't bounce to the actual real originator, but to the local user. So in this way the spammer manages to deliver the spam to the addrassee, although it is filtered my spamassassin, abusing the bounce concept. I searched the internet about disabling boune messages, and came across a post, where Wietse Venema wrote, that he will not allow "over his dead body" disabling bouncing. Now, maybe I misunderstand something here, and my problem and the quoted post do not relate to the same kind of bounces. It seems to me, that this type of bounce is highly undesirable, so how to avoid it? In my exim setup I silently sent all suspicious mail (virus infected ot spam) to a special acount, where it would get deleted automatically after one month. I kept it there in case some user complined about not receiving a specific mail. I did not generate bounce mails, and did not reject delivery. Basically, I want to do the same now. kind regards, Marcus PS: output of postconf -n: bash-3.2# postconf -n biff = no command_directory = /usr/sbin config_directory = /etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/libexec/postfix debug_peer_level = 2 enable_server_options = yes header_checks = pcre:/etc/postfix/custom_header_checks html_directory = /usr/share/doc/postfix/html inet_interfaces = all mail_owner = _postfix mailbox_size_limit = 0 mailbox_transport = dovecot mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 104857600 mydestination = $myhostname, localhost.$mydomain, localhost mydomain = s44.at mydomain_fallback = localhost myhostname = server.s44.at mynetworks = 127.0.0.0/8 newaliases_path = /usr/bin/newaliases queue_directory = /private/var/spool/postfix readme_directory = /usr/share/doc/postfix recipient_delimiter = + relayhost = sample_directory = /usr/share/doc/postfix/examples sendmail_path = /usr/sbin/sendmail setgid_group = _postdrop smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated permit smtpd_enforce_tls = no smtpd_helo_required = yes smtpd_helo_restrictions = reject_invalid_helo_hostname reject_non_fqdn_helo_hostname smtpd_pw_server_security_options = cram-md5,gssapi,plain,login smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_policy_service unix:private/policy permit smtpd_sasl_auth_enable = yes smtpd_tls_CAfile = /etc/certificates/server.s44.at.4EF6136BE9E4DFBF0724E064F5B5FB3DD9856EC2.chain.pem smtpd_tls_cert_file = /etc/certificates/server.s44.at.4EF6136BE9E4DFBF0724E064F5B5FB3DD9856EC2.cert.pem smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL smtpd_tls_key_file = /etc/certificates/server.s44.at.4EF6136BE9E4DFBF0724E064F5B5FB3DD9856EC2.key.pem smtpd_tls_loglevel = 0 smtpd_use_pw_server = yes smtpd_use_tls = yes unknown_local_recipient_reject_code = 550 virtual_alias_domains = $virtual_alias_maps hash:/etc/postfix/virtual_domains virtual_alias_maps = hash:/etc/postfix/virtual_users
Re: Question about bounce related spam
On 2010-04-18 8:10 AM, Marcus Frischherz wrote: > The spam gets filtered alright by spamassassin, and then it bounces, but > it doesn't bounce to the actual real originator, but to the local user. > So in this way the spammer manages to deliver the spam to the addrassee, > although it is filtered my spamassassin, abusing the bounce concept. That is your problem. Either set up your anti-spam filter as a pre-queue filter, so you can smtp reject it, rather than accept>bounce it, or do *not* bounce it but deliver it tagged and/or to a spam folder. What you are enagging in is called backscatter, and can eventually get you blacklisted if your server is high enough volume: http://www.postfix.org/BACKSCATTER_README.html -- Best regards, Charles
Re: Question about bounce related spam
Am 18.04.10 14:37, schrieb Charles Marcus: On 2010-04-18 8:10 AM, Marcus Frischherz wrote: The spam gets filtered alright by spamassassin, and then it bounces, but it doesn't bounce to the actual real originator, but to the local user. So in this way the spammer manages to deliver the spam to the addrassee, although it is filtered my spamassassin, abusing the bounce concept. That is your problem. Either set up your anti-spam filter as a pre-queue filter, so you can smtp reject it, rather than accept>bounce it, or do *not* bounce it but deliver it tagged and/or to a spam folder. What you are enagging in is called backscatter, and can eventually get you blacklisted if your server is high enough volume: http://www.postfix.org/BACKSCATTER_README.html Thanks for the link. I read it, and I realize that it is related to my problem. However, this link describes how to block incoming bckscatter, while my problem seems to be, that postfix with these settings creates backscatter (maybe relaying it to outside users as well, certainly, as evidenced by my mail box, internally). This is exactly the reason why I want to disable the bounce, and the question is how. Temporarilly I commented out the line #bounceunix - - n - 0 bounce in master.cf, but I think that this is not the ideal solution, as now undeliverable mails start queuing up. regards, Marcus
Re: Question about bounce related spam
Marcus Frischherz a écrit : >[snip] > Thanks for the link. I read it, and I realize that it is related to my > problem. However, this link describes how to block incoming bckscatter, > while my problem seems to be, that postfix with these settings creates > backscatter (maybe relaying it to outside users as well, certainly, as > evidenced by my mail box, internally). This is exactly the reason why I > want to disable the bounce, and the question is how. Temporarilly I > commented out the line > #bounceunix - - n - 0 bounce > don't do that. people will lose mail... > in master.cf, but I think that this is not the ideal solution, as now > undeliverable mails start queuing up. > the config is in amavisd-new, not in postfix. In amavisd.conf, use $final_spam_destiny = D_PASS; so that spam is delivered (and not rejected/bounced) then configure your delivery mechanism to put spam in a Spam folder (assuming IMAP or webmail, not POP3). alternatively, configure amavisd-new to quarantine spma. but then you'll need a way to handle the quarantine. in postfix, consider using reject_rbl_client zen.spamhaus.org in your access checks. search postfix docs or the web if this is unclear.
Re: Question about bounce related spam
On 2010-04-18 9:47 AM, Marcus Frischherz wrote: >> What you are enagging in is called backscatter, and can eventually get >> you blacklisted if your server is high enough volume: >> >> http://www.postfix.org/BACKSCATTER_README.html > Thanks for the link. I read it, and I realize that it is related to my > problem. However, this link describes how to block incoming back-scatter, > while my problem seems to be, that postfix with these settings creates > backscatter (maybe relaying it to outside users as well, certainly, as > evidenced by my mail box, internally). Postfix is only doing what you told it to do. I sent the link so you'd understand what back-scatter is. > This is exactly the reason why I want to disable the bounce, and the > question is how. Temporarilly I commented out the line > #bounceunix - - n - 0 bounce > > in master.cf, but I think that this is not the ideal solution, as now > undeliverable mails start queuing up. Please show entire master.cf file... I don't use spamassassin, so can't tell you off the top of my head how to tell it to stop rejecting mail it detects as spam, but I'm pretty sure it depends on how you have integrated it. Are you using amavisd-new? -- Best regards, Charles
Re: Question about bounce related spam
Am 18.04.10 16:07, schrieb Charles Marcus: Please show entire master.cf file... I don't use spamassassin, so can't tell you off the top of my head how to tell it to stop rejecting mail it detects as spam, but I'm pretty sure it depends on how you have integrated it. Are you using amavisd-new? I reenabled the bounce in master.cf, and followed another suggestion by user mouss, which came in response to my question, who also told me that this behaviour must be amavis related. I am testing this setting now. Well, what I am really using is a bit difficult to say. I am using, whatever Apple sees fit for the Mac OSX Server, but it certainly includes amavis (or amavis-new, who knows). regards
Re: Protection against stolen credentials?
El 16/04/10 23:33, John Fawcett escribió: I've been using cbpolicyd to do rate limiting on submission port not because I want to rate limit legitimate users, but to protect against stolen credentials. The approach of scanning the logfile that you outline, though not real time like cbpolicyd would be almost as good if run often enough so that the window in which spam could leak out was small. So I have made a prototype (sorry but it's php not perl) that can parse log files and write postfix access files. It does not do all you wanted, for example the part about country lookups, though feasible would not catch the case of stolen credentials from ips within the same country. I have only implemented two limits: a limit on number of authentications within a certain time frame and limit on the number of different ips for a single user in the time frame. If either limit is reached then the IP is blacklilsted in an access file. Maybe it is useful or you could extend it for your needs. http://www.gufonero.com/postfix/check_auth_log_0.1.tgz After customizing file locations and limits, you can schedule the script to run from cron, but you need to also include the postmap of the access file (makefile -f check_auth_log_makefile all) afterwards. It assumes you use hash access files. Update of main.cf / master.cf is needed to add in the check of the access map, e.g. for the submission port. You'd probably also want a whitelist access file in front of this to opt certain heavy users out of the check. regards, John John, thanks so much for your interest. I just downloaded it. Tomorrow I will be meeting my partner (he's the php guy) adn we will take a look at it. I'll certainly keep you posted of any developments. Best regards, Ignacio
Re: Append a custom head via a filter, partially OT
On Thu, Apr 15, 2010 at 1:02 AM, Gary Smith wrote:
> We use a filter to break out and run our spamassassin and other checks. In
> bash shell that process, we have a need to insert a custom unique header per
> email for compliance. Is there a simple way of doing this without having to
> go into any special mime processing of the message?
>
> Gary Smith
>
Add to bash script:
sed -i '0,/^$/s//X-unique-header: ${VAR_UNIQUE_VALUE}\n/' "$FILE"
Plesae, set VAR_UNIQUE_VALUE and FILE as apropriated.
--
Reinaldo de Carvalho
http://korreio.sf.net
http://python-cyrus.sf.net
"Don't try to adapt the software to the way you work, but rather
yourself to the way the software works" (myself)
Receiving bounce messages back to local-host
Following the firewall/smtp relay page http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall Process - internal servers *send* through *my-relay* - *my-relay* forwards to *master-relay* - valid email is passing through for all the clients as expected. - *master-relay* kicks back any undeliverable emails to *my-relay* I want the undeliverable email to be sent and received on *my-relay* and not my work account. - I work with end users to "fix" their undeliverable issue. -- Bounce messages are *not* being received back from the *master-relay* to *my-relay*. Particulars -- OS: CentOS 5.4 -- my-dom.TLD = my domain -- SUB-DOM= my sub domain Postfinger --System Parameters-- mail_version = 2.5.1 hostname = mailhost.SUB-DOM.my-dom.TLD uname = Linux mailhost.SUB-DOM.my-dom.TLD 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:37:14 EDT 2010 i686 i686 i386 GNU/Linux --Packaging information-- looks like this postfix comes from RPM package: postfix-2.5.1-1.rhel5 --main.cf non-default parameters-- alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases html_directory = /usr/share/doc/postfix-2.5.1-documentation/html local_transport = error:local mail delivery is disabled mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mime_header_checks = regexp:/etc/postfix/mime_header_checks.regexp mydestination = mynetworks = ppp.pp.0.0/16, DDD.dd.0.0/16 newaliases_path = /usr/bin/newaliases.postfix readme_directory = /usr/share/doc/postfix-2.5.1-documentation/readme relay_domains = SUB-DOM.my-dom.TLD, my-dom.TLD relayhost = *master-relay*.my-dom.TLD sendmail_path = /usr/sbin/sendmail.postfix smtpd_data_restrictions = reject_unauth_pipelining,permit_mynetworks transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 450 virtual_alias_maps = hash:/etc/postfix/virtual --master.cf-- smtp inet n - n - - smtpd pickupfifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr tlsmgrunix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounceunix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verifyunix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp relay unix - - n - - smtp -o smtp_fallback_relay= showq unix n - n - - showq error unix - - n - - error retry unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil scacheunix - - n - 1 scache -- end of postfinger output -- -- /etc/postfix/virtual rootr...@mailhost.sub-dom.my-dom.tld mem...@mailhost.sub-dom.my-dom.tld -- /etc/postfix/aliases #root:m...@my-domain.tld root:m...@localhost Thx CT
Unknown senders and spam
Hi, I'm wondering about some messages with Received headers such as this: Received: from zaphod.chipchaps.com (unknown [65.182.186.13]) It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a spam site), which resolves back to 65.182.186.12. Is this where the problem is? I'm not sure if I'm having a DNS problem with my resolver not being able to find the answer in time (or at all), or I'm possibly not understanding how to do this properly. I'd like to determine if I can add additional restrictions in postfix to limit connections from hosts that don't resolve properly, but before I can do that I need to make sure my DNS is working properly. Maybe I'm able to resolve it now but wasn't able to when the email arrived? Maybe the DNS info has changed since the email was received? What are the risks or implications of denying messages of this type? Thanks, Alex
Re: Unknown senders and spam
Alex: > Hi, > > I'm wondering about some messages with Received headers such as this: > > Received: from zaphod.chipchaps.com (unknown [65.182.186.13]) > > It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a > spam site), which resolves back to 65.182.186.12. Is this where the > problem is? The definition of an "unknown" client hostname is given in http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname which, as the name suggests, rejects mail from a client with a hostname that Postfix considers "unknown". Wietse > I'm not sure if I'm having a DNS problem with my resolver not being > able to find the answer in time (or at all), or I'm possibly not > understanding how to do this properly. I'd like to determine if I can > add additional restrictions in postfix to limit connections from hosts > that don't resolve properly, but before I can do that I need to make > sure my DNS is working properly. Maybe I'm able to resolve it now but > wasn't able to when the email arrived? Maybe the DNS info has changed > since the email was received? > > What are the risks or implications of denying messages of this type? > > Thanks, > Alex > >
Re: Receiving bounce messages back to local-host
Following the firewall/smtp relay page http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall Process - internal servers *send* through *my-relay* - *my-relay* forwards to *master-relay* - valid email is passing through for all the clients as expected. - *master-relay* kicks back any undeliverable emails to *my-relay* I want the undeliverable email to be sent and received on *my-relay* and not my work account. - I work with end users to "fix" their undeliverable issue. -- Bounce messages are *not* being received back from the *master-relay* to *my-relay*. Particulars -- OS: CentOS 5.4 -- my-dom.TLD = my domain -- SUB-DOM= my sub domain Postfinger --System Parameters-- mail_version = 2.5.1 hostname = mailhost.SUB-DOM.my-dom.TLD uname = Linux mailhost.SUB-DOM.my-dom.TLD 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:37:14 EDT 2010 i686 i686 i386 GNU/Linux --Packaging information-- looks like this postfix comes from RPM package: postfix-2.5.1-1.rhel5 --main.cf non-default parameters-- alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases html_directory = /usr/share/doc/postfix-2.5.1-documentation/html local_transport = error:local mail delivery is disabled mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mime_header_checks = regexp:/etc/postfix/mime_header_checks.regexp mydestination = mynetworks = ppp.pp.0.0/16, DDD.dd.0.0/16 newaliases_path = /usr/bin/newaliases.postfix readme_directory = /usr/share/doc/postfix-2.5.1-documentation/readme relay_domains = SUB-DOM.my-dom.TLD, my-dom.TLD relayhost = *master-relay*.my-dom.TLD sendmail_path = /usr/sbin/sendmail.postfix smtpd_data_restrictions = reject_unauth_pipelining,permit_mynetworks transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 450 virtual_alias_maps = hash:/etc/postfix/virtual --master.cf-- smtp inet n - n - - smtpd pickupfifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr tlsmgrunix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounceunix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verifyunix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp relay unix - - n - - smtp -o smtp_fallback_relay= showq unix n - n - - showq error unix - - n - - error retry unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil scacheunix - - n - 1 scache -- end of postfinger output -- -- /etc/postfix/virtual rootr...@mailhost.sub-dom.my-dom.tld mem...@mailhost.sub-dom.my-dom.tld -- /etc/postfix/aliases #root:m...@my-domain.tld root:m...@localhost Thx CT I had asked this about 2 weeks ago but could not test it until it was in place.. I did try the mydestination = $myhostname and mydestination = $my-SUB-DOMAIN.. Thx Ct
Re: Unknown senders and spam
Hi, >> Received: from zaphod.chipchaps.com (unknown [65.182.186.13]) >> >> It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a >> spam site), which resolves back to 65.182.186.12. Is this where the >> problem is? > > The definition of an "unknown" client hostname is given in > http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname > which, as the name suggests, rejects mail from a client with a hostname > that Postfix considers "unknown". Is it common practice to have that restriction in a production environment? It appears to be the third case here, that the name->address mapping does not match the client IP address. Could this be from a legitimate cause, or typically intentionally to be evasive? Could it be found in a legitimate dynamic environment, such as at an ISP? Is there a way to log these specific failures so I can get a better idea of under what circumstances they occur in my environment? I'm currently rejecting the following, in this order: reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unauth_destination, reject_maps_rbl, Thanks, Alex
Re: Unknown senders and spam
Alex: > Hi, > > >> ? ? Received: from zaphod.chipchaps.com (unknown [65.182.186.13]) > >> > >> It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a > >> spam site), which resolves back to 65.182.186.12. Is this where the > >> problem is? > > > > The definition of an "unknown" client hostname is given in > > http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname > > which, as the name suggests, rejects mail from a client with a hostname > > that Postfix considers "unknown". > > Is it common practice to have that restriction in a production environment? Yes, if the tolerance for spam is worse than the tolerance for mail not received. [speculation deleted] > Is there a way to log these specific failures so I can get a better > idea of under what circumstances they occur in my environment? Postfix logs a warning when the reverse name does not resolve, or when the reverse name resolves to the wrong address: warning: 1.2.3.4: hostname example.com verification failed: Host not found, try again warning: 1.2.3.4: address not listed for hostname example.com When you report a problem, it is a good idea to look at the warning messages in the Postfix logfile. Wietse
Wanting incoming and outgoing e-mail montiroed for spam and virii
Right I am tyring to get postfix with amavisd-ng to probe and stop virus and spam mail. However it seems that localhost is going through without scrutiny and some incoming e-mail is not being stopped. postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases body_checks = regexp:/etc/postfix/body_checks broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix content_filter = amavisfeed:[127.0.0.1]:10024 cyrus_sasl_config_path = /usr/contrib/lib/sasl2/ daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debug_peer_list = nk.ca disable_vrfy_command = yes fast_flush_domains = $relay_domains, nk.ca, nl2k.ab.ca hash_queue_names = " " defer deferred header_checks = regexp:/etc/postfix/header_checks html_directory = /var/www/docs/postfix in_flow_delay = 1s inet_interfaces = all local_destination_concurrency_limit = 2 local_recipient_maps = unix:passwd.byname $alias_maps local_transport = local mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = /usr/bin/procmail mailbox_size_limit = 104857600 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 2100 milter_protocol = 6 mydestination = $myhostname, localhost.$mydomain, localhost, www.$mydomain, ns1.$mydomain, ftp.$mydomain, secure.$mydomain, localhost.nl2k.ab.ca , localhost.nk.ca , $mydomain, mail.nk.ca, www.nk.ca, nk.ca, valid.nk.ca, secure.nl2k.ab.ca, dspam.nk.ca, dspam.netknow.ca, dspam.nl2k.ca, dspam.nl2k.ab.ca, edmontonab.ca, internetedmonton.ca, edmontoninternetserviceprovider.ca, internetalberta.ca, albertainternet.ca, albertainternetserviceprovider.ca, netknow.ca, nl2k.ca, nl2k.ab.ca, valid.nl2k.ab.ca, secure.nl2k.ab.ca, mail.nl2k.ab.ca, home.nl2k.ab.ca mydomain = nk.ca myhostname = doctor.nl2k.ab.ca mynetworks = 204.209.81.0/24, 208.118.93.0/24, 208.118.94.0/24, 127.0.0.0/8 mynetworks_style = host myorigin = $myhostname newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = no relay_domains = $virtual_alias_domains relay_recipient_maps = hash:/etc/postfix/access sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtp_tls_CAfile = /etc/postfix/cacert.pem smtp_tls_loglevel = 2 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) smtpd_client_restrictions = check_client_access hash:/etc/postfix/access smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_error_sleep_time = 0 smtpd_helo_required = yes smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname,reject_non_fqdn_sender, reject_non_fqdn_recipient,reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unverified_recipient,permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, reject_rbl_client sbl-xbl.spamhaus.org,reject_rbl_client zen.spamhaus.org,reject_rbl_client dnsbl.njabl.org, reject_rbl_client combined.njabl.org, reject_rbl_client dev.null.dk, reject_rbl_client flowgoaway.com, reject_rbl_client relays.visi.com, reject_rbl_client bl.spamcop.net, reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2, permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = mail.nk.ca smtpd_sasl_path = smtpd smtpd_tls_CAfile = /etc/postfix/cacert.pem smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/postfix/mail.nk.ca.2009.cert.pem smtpd_tls_key_file = /etc/postfix/mail.nk.ca.2009.key.pem smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache smtpd_use_tls = yes soft_bounce = yes strict_rfc821_envelopes = yes tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_domains = virtual_alias_maps = hash:/etc/postfix/virtual And the master.cf is # # Postfix master process configuration file. For details on the format # of the file, see the Postfix master(5) manual page. # # == # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # == smtp inet n - n - - smtpd -o smtpd_proxy_filter=127.0.0.1:10125 -o content_filter=amavisfeed:[120.0.0.1]:10024 ## -o cleanup_service_name=pre-cleanup 127.
Re: Wanting incoming and outgoing e-mail montiroed for spam and virii
On Sun, Apr 18, 2010 at 01:26:49PM -0600, The Doctor wrote: > Right I am tyring to get postfix with amavisd-ng to probe and stop > virus and spam mail. > > However it seems that localhost is going through without scrutiny and > some incoming e-mail is not being stopped. > > Am I missing something? LOGS. The phrase "going through without scrutity" is vague and lacks specificity with regard to the observed symptoms You must provide clear explanation of which filtering you expected to get, and what you got instead (LOGS). And the configuration again with all of that, so that one does not have to re-assemble the full problem descrition from fragments of multiple messages. -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
Re: Wanting incoming and outgoing e-mail montiroed for spam and virii
The Doctor a écrit : > Right I am tyring to get postfix with amavisd-ng to probe and stop virus and > spam mail. use amavisd-new instead of amavis-ng. > > However it seems that localhost is going through without scrutiny and > some incoming e-mail is not being stopped. > what do you mean by "localhost is going through"? if you talk about mail submitted via the sendmail command, then it's because you have "-o content_filter=" under pickup (in master.cf). if you meant something else, please explain. anyway, why would spam get out of localhost? is it because of a web application? if so, better make the application use SMTP instead of the sendmail. > [snip] > pickupfifo n - n 60 1 pickup >-o content_filter= > ##-o cleanup_service_name=pre-cleanup it's just here. you are disabling the content filter for pickup. > [snip]
Re: Unknown senders and spam
Alex a écrit : > Hi, > >>> Received: from zaphod.chipchaps.com (unknown [65.182.186.13]) >>> >>> It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a >>> spam site), which resolves back to 65.182.186.12. Is this where the >>> problem is? >> The definition of an "unknown" client hostname is given in >> http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname >> which, as the name suggests, rejects mail from a client with a hostname >> that Postfix considers "unknown". > > Is it common practice to have that restriction in a production environment? > > It appears to be the third case here, that the name->address mapping > does not match the client IP address. Could this be from a legitimate > cause, or typically intentionally to be evasive? > since they put their domain name in their HELO (zaphod.chipchaps.com), they're not trying to evade anything. you could try check_client_access hash:/etc/postfix/access_unknown smtpd_restriction_classes = ... policy_strong policy_strong = reject_rbl_client bb.barracudacentral.org ... == access_unknown unknown policy_strong as usual, use at your own risk! you can try it with warn_if_reject for some time if that makes you feel more confident (and no, I don't use such a check). > Could it be found in a legitimate dynamic environment, such as at an ISP? no, these are spammers (illegal "work from home"). the domain probably belongs to "Global Innovative Marketing" as you can find by visiting their web page (www.chipchaps...) then clicking on the link at the bottom, which leads you to a privacy page, and if you scroll down, you get br...@myvemmaoffice.com. whois of the latter gives "Global Innovative Marketing" (both chipchaps and bvconsulting.org have hidden whois). anyway, - www.chipchaps... sis enough to convince you they are spammers. - they have two IPs (.12 and .13) inside a range of IPs with generic names belonging to pugmarks.com, who provide hosting... Also look at Senderbase: http://www.senderbase.org/senderbase_queries/detailip?search_string=65.182.186.0%2F24 you can probably block the whole range... > > Is there a way to log these specific failures so I can get a better > idea of under what circumstances they occur in my environment? > > I'm currently rejecting the following, in this order: > > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_unauth_pipelining, > reject_invalid_hostname, > reject_non_fqdn_hostname, > reject_unauth_destination, > reject_maps_rbl, > > Thanks, > Alex
Re: Receiving bounce messages back to local-host
On 4/18/2010 11:21 AM, CT wrote: Following the firewall/smtp relay page http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall Process - internal servers *send* through *my-relay* - *my-relay* forwards to *master-relay* - valid email is passing through for all the clients as expected. - *master-relay* kicks back any undeliverable emails to *my-relay* I want the undeliverable email to be sent and received on *my-relay* and not my work account. - I work with end users to "fix" their undeliverable issue. -- Bounce messages are *not* being received back from the *master-relay* to *my-relay*. Sorry, your question isn't entirely clear to me. Bounces are always sent to the envelope sender. If a downstream relay isn't returning bounces to the envelope sender, you need to take that up with the operators of the downstream relay. If you need to control which user receives the bounce, adjust the envelope sender on OUTGOING mail. If this doesn't cover your question, please try to rephrase or show logs of what occurs vs. what you expect to happen. -- Noel Jones Particulars -- OS: CentOS 5.4 -- my-dom.TLD = my domain -- SUB-DOM = my sub domain Postfinger --System Parameters-- mail_version = 2.5.1 hostname = mailhost.SUB-DOM.my-dom.TLD uname = Linux mailhost.SUB-DOM.my-dom.TLD 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:37:14 EDT 2010 i686 i686 i386 GNU/Linux --Packaging information-- looks like this postfix comes from RPM package: postfix-2.5.1-1.rhel5 --main.cf non-default parameters-- alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases html_directory = /usr/share/doc/postfix-2.5.1-documentation/html local_transport = error:local mail delivery is disabled mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mime_header_checks = regexp:/etc/postfix/mime_header_checks.regexp mydestination = mynetworks = ppp.pp.0.0/16, DDD.dd.0.0/16 newaliases_path = /usr/bin/newaliases.postfix readme_directory = /usr/share/doc/postfix-2.5.1-documentation/readme relay_domains = SUB-DOM.my-dom.TLD, my-dom.TLD relayhost = *master-relay*.my-dom.TLD sendmail_path = /usr/sbin/sendmail.postfix smtpd_data_restrictions = reject_unauth_pipelining,permit_mynetworks transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 450 virtual_alias_maps = hash:/etc/postfix/virtual --master.cf-- smtp inet n - n - - smtpd pickup fifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr tlsmgr unix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp relay unix - - n - - smtp -o smtp_fallback_relay= showq unix n - n - - showq error unix - - n - - error retry unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil scache unix - - n - 1 scache -- end of postfinger output -- -- /etc/postfix/virtual root r...@mailhost.sub-dom.my-dom.tld me m...@mailhost.sub-dom.my-dom.tld -- /etc/postfix/aliases #root: m...@my-domain.tld root: m...@localhost Thx CT
Re: Receiving bounce messages back to local-host
Following the firewall/smtp relay page http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall Process - internal servers *send* through *my-relay* - *my-relay* forwards to *master-relay* - valid email is passing through for all the clients as expected. - *master-relay* kicks back any undeliverable emails to *my-relay* I want the undeliverable email to be sent and received on *my-relay* and not my work account. - I work with end users to "fix" their undeliverable issue. -- Bounce messages are *not* being received back from the *master-relay* to *my-relay*. Sorry, your question isn't entirely clear to me. Bounces are always sent to the envelope sender. If a downstream relay isn't returning bounces to the envelope sender, you need to take that up with the operators of the downstream relay. If you need to control which user receives the bounce, adjust the envelope sender on OUTGOING mail. If this doesn't cover your question, please try to rephrase or show logs of what occurs vs. what you expect to happen. -- Noel Jones Noel, Thanks for the reply.. I *guess* I was wanting to know that the configuration I *do* have is configured correctly to receive an invalid message sent *through* my relay.. This relay is replacing the old Sendmail relay .. Some clarification. [send only host] => [*my-relay*] => [*master-relay*] => Final-Recipient in the case that the Final-Recipient is invalid for whatever reason.. the *master-relay* returns the message back to *my-relay* .. since the send only host can't receive "their invalid" message it ends up in my queue and then times out.. This worked without incident on the old Sendmail relay.. so I am sure that the (downstream relay) configuration is correct... and the issue is with my new relay.. btw (I will be talking to the downstream relay admin tomorrow to see if they can give me any ideas) I am thinking that I might just need to remove this line local_transport = error:local mail delivery is disabled Hope this clarifies the issue.. I really think I am missing something very basic.. and just can't see it.. Thx Charles
Re: Receiving bounce messages back to local-host
On 4/18/2010 3:38 PM, Charles wrote: Following the firewall/smtp relay page http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall Process - internal servers *send* through *my-relay* - *my-relay* forwards to *master-relay* - valid email is passing through for all the clients as expected. - *master-relay* kicks back any undeliverable emails to *my-relay* I want the undeliverable email to be sent and received on *my-relay* and not my work account. - I work with end users to "fix" their undeliverable issue. -- Bounce messages are *not* being received back from the *master-relay* to *my-relay*. Sorry, your question isn't entirely clear to me. Bounces are always sent to the envelope sender. If a downstream relay isn't returning bounces to the envelope sender, you need to take that up with the operators of the downstream relay. If you need to control which user receives the bounce, adjust the envelope sender on OUTGOING mail. If this doesn't cover your question, please try to rephrase or show logs of what occurs vs. what you expect to happen. -- Noel Jones Noel, Thanks for the reply.. I *guess* I was wanting to know that the configuration I *do* have is configured correctly to receive an invalid message sent *through* my relay.. This relay is replacing the old Sendmail relay .. Some clarification. [send only host] => [*my-relay*] => [*master-relay*] => Final-Recipient in the case that the Final-Recipient is invalid for whatever reason.. the *master-relay* returns the message back to *my-relay* .. since the send only host can't receive "their invalid" message it ends up in my queue and then times out.. This worked without incident on the old Sendmail relay.. so I am sure that the (downstream relay) configuration is correct... and the issue is with my new relay.. btw (I will be talking to the downstream relay admin tomorrow to see if they can give me any ideas) I am thinking that I might just need to remove this line local_transport = error:local mail delivery is disabled If the envelope sender (bounce recipient) domain is listed in $mydestination, then yes, you should remove this line OR arrange for that recipient to be delivered elsewhere OR use a different envelope sender that is deliverable. Hope this clarifies the issue.. Postfix logs help you know what happened to a particular message. Look in your logs for bounces (sender=<>) arriving from your relayhost, and see what postfix does with it. No need to wonder where they went. -- Noel Jones
Re: Receiving bounce messages back to local-host
Following the firewall/smtp relay page http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall Process - internal servers *send* through *my-relay* - *my-relay* forwards to *master-relay* - valid email is passing through for all the clients as expected. - *master-relay* kicks back any undeliverable emails to *my-relay* I want the undeliverable email to be sent and received on *my-relay* and not my work account. - I work with end users to "fix" their undeliverable issue. -- Bounce messages are *not* being received back from the *master-relay* to *my-relay*. Sorry, your question isn't entirely clear to me. Bounces are always sent to the envelope sender. If a downstream relay isn't returning bounces to the envelope sender, you need to take that up with the operators of the downstream relay. If you need to control which user receives the bounce, adjust the envelope sender on OUTGOING mail. If this doesn't cover your question, please try to rephrase or show logs of what occurs vs. what you expect to happen. -- Noel Jones Noel, Thanks for the reply.. I *guess* I was wanting to know that the configuration I *do* have is configured correctly to receive an invalid message sent *through* my relay.. This relay is replacing the old Sendmail relay .. Some clarification. [send only host] => [*my-relay*] => [*master-relay*] => Final-Recipient in the case that the Final-Recipient is invalid for whatever reason.. the *master-relay* returns the message back to *my-relay* .. since the send only host can't receive "their invalid" message it ends up in my queue and then times out.. This worked without incident on the old Sendmail relay.. so I am sure that the (downstream relay) configuration is correct... and the issue is with my new relay.. btw (I will be talking to the downstream relay admin tomorrow to see if they can give me any ideas) I am thinking that I might just need to remove this line local_transport = error:local mail delivery is disabled If the envelope sender (bounce recipient) domain is listed in $mydestination, then yes, you should remove this line OR arrange for that recipient to be delivered elsewhere OR use a different envelope sender that is deliverable. Hope this clarifies the issue.. Postfix logs help you know what happened to a particular message. Look in your logs for bounces (sender=<>) arriving from your relayhost, and see what postfix does with it. No need to wonder where they went. -- Noel Jones A lot of the send only hosts have only an IP (not in DNS) Apr 18 16:01:24 mailhost postfix/qmgr[3283]: 5BE9956799: from=<>, size=89424, nrcpt=1 (queue active) but nothing is in the active queue.. Will keep looking.. Thx again.. Charles But there is nothing in /var/
Re: Receiving bounce messages back to local-host
On 4/18/2010 4:16 PM, groups wrote: Postfix logs help you know what happened to a particular message. Look in your logs for bounces (sender=<>) arriving from your relayhost, and see what postfix does with it. No need to wonder where they went. -- Noel Jones A lot of the send only hosts have only an IP (not in DNS) Look in the logs for the IP to find associated QUEUEIDs. Apr 18 16:01:24 mailhost postfix/qmgr[3283]: 5BE9956799: from=<>, size=89424, nrcpt=1 (queue active) Look in the logs for other entries with that same QUEUEID 5BE9956799 to see other information associated with that transaction.
Re: Receiving bounce messages back to local-host
Noel Jones wrote, On 04/18/2010 04:20 PM: On 4/18/2010 4:16 PM, groups wrote: Postfix logs help you know what happened to a particular message. Look in your logs for bounces (sender=<>) arriving from your relayhost, and see what postfix does with it. No need to wonder where they went. -- Noel Jones A lot of the send only hosts have only an IP (not in DNS) Look in the logs for the IP to find associated QUEUEIDs. Apr 18 16:01:24 mailhost postfix/qmgr[3283]: 5BE9956799: from=<>, size=89424, nrcpt=1 (queue active) Look in the logs for other entries with that same QUEUEID 5BE9956799 to see other information associated with that transaction. only 1 entry per transaction ID.. notthing in /var/spool/postfix ... ok.. and found something interesting.. Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 04C2A56799: from=<>, size=83199, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 2B54756799: from=<>, size=83614, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 4D99856799: from=<>, size=84029, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 7B1F756799: from=<>, size=8, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 9BD4456799: from=<>, size=84859, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: BF6DC56799: from=<>, size=85274, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: E147056799: from=<>, size=85689, nrcpt=1 (queue active) All have the same invalid recipient.. Almost looks like it is "ping-ponging" back and forth between the *master-relay* and my relay.. I have seen this invalid recipient on the old Sendmail box.. and it ended up in my queue then expires.. (the sender host has been out of the office when I tried to contact them) so it looks like I have something not right.. there is nothing in mailq.. Charles
Re: Unknown senders and spam
Hi, >> Is it common practice to have that restriction in a production environment? >> >> It appears to be the third case here, that the name->address mapping >> does not match the client IP address. Could this be from a legitimate >> cause, or typically intentionally to be evasive? >> > > since they put their domain name in their HELO (zaphod.chipchaps.com), > they're not trying to evade anything. Yes, I guess they would have been rejected as a result of my helo checks. > you could try > > check_client_access hash:/etc/postfix/access_unknown > > > smtpd_restriction_classes = > ... > policy_strong > > policy_strong = > reject_rbl_client bb.barracudacentral.org Is it possible to use maps_rbl_domains instead of reject_rbl_client here? It appears this machine has a version of postfix that doesn't understand reject_rbl_client. Thanks again! Best regards, Alex
Re: Unknown senders and spam
Alex put forth on 4/18/2010 4:45 PM: > Is it possible to use maps_rbl_domains instead of reject_rbl_client > here? It appears this machine has a version of postfix that doesn't > understand reject_rbl_client. maps_rbl_domains (default: empty) Obsolete feature: use the reject_rbl_client feature instead. reject_rbl_client rbl_domain=d.d.d.d ... *** This feature is available in Postfix 2.0 and later. *** (emphasis mine) Your statement leads me to believe you're using a Postfix version less than 2.0. IIRC, versions less than 2.3 are no longer supported. It appears you _really_ need to upgrade Postfix on that host. And given that it's likely a distribution package, you probably really need to update the OS on that host as well. -- Stan
Re: Unknown senders and spam
Hi, > maps_rbl_domains (default: empty) > > Obsolete feature: use the reject_rbl_client feature instead. Yes, that was why I was asking. It's a really old version of postfix I'm still using on this host for now, until I can migrate to an entirely new server and at the same time keep this one running. I just wanted to confirm that this feature, or an equivalent, isn't available in old versions of postfix? Thanks, Alex
Re: recipient_delimiter is not set
Thanks to Sahil Tandon and LuKreme for pointing out my mistake on the debugging tool. I saw this done in an old archived post, and having searched for but not found the "what to include in a problem report" FAQ item, I winged it, incorrectly. I also forgot to specify the version of Postfix: 2.6.1 from OpenSuSE 11.2. So when mail is sent to user+extension, how do I capture the extension? I solved my problem partially, by cowboy programming. I never did see the EXTENSION environment variable being set, but ORIGINAL_RECIPIENT semi-reliably includes user+extens...@domain, so by parsing that, I was able to extract the extension and interpret that as the name of the mailing list. The only problem is composite lists. Suppose /etc/aliases says: logs: reports, programmers programmers: listmonkey+programm...@julia If someone on Julia sends to logs, the first alias is expanded instantly and ORIGINAL_RECIPIENT remains as "logs". The way I dealt with it is to say logs: reports, programm...@sumac where Sumac is our MX and nobody ever originates messages from there. In the source code for local(8) it was clear that EXTENSION would have been set if the message structure had msg_attr.extension, which is set in deliver_recipient, and clearly the extension is removed from msg_attr.user at that point (because Julia delivered it to listmonkey, which is a user, and not listmonkey+testmonkey, which isn't), but I can't see why it is not available in deliver_command(). If anyone could shed some light on the right way to capture the extension, I would really appreciate it. I've appended the output from postconf -n. James F. Carter Voice 310 825 2897FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: j...@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key) alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases, nis:mail.aliases best_mx_transport = local biff = no bounce_queue_lifetime = 150m broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix debug_peer_level = 2 default_destination_concurrency_limit = 2 disable_dns_lookups = no html_directory = /usr/share/doc/packages/postfix/html mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = /usr/bin/procmail -Y -t -a "$DOMAIN" -d "$USER" mailbox_size_limit = 5 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_domains = $mydomain masquerade_exceptions = root mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain mydomain = math.ucla.edu mynetworks = 128.97.4.0/24, 128.97.19.0/24, 128.97.70.0/24, 128.97.12.0/24 127.0.0.0/8 newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix/README_FILES recipient_delimiter = + relay_clientcerts = hash:/etc/postfix/relay_ccerts relay_domains = $mynetworks require_home_directory = no sample_directory = /usr/share/doc/packages/postfix/samples sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_sasl_auth_enable = no smtp_tls_CAfile = /etc/ssl/certs/ucla-math.crt smtp_tls_CApath = /etc/ssl/certs smtp_tls_cert_file = /etc/ssl/hostcerts/host.crt smtp_tls_key_file = /etc/ssl/private/host.key smtp_tls_session_cache_database = btree:/var/lib/postfix/client_scache smtp_tls_session_cache_timeout = 3600s smtp_use_tls = yes smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) UCLA-Mathnet smtpd_client_restrictions = permit_tls_all_clientcerts, permit_sasl_authenticated, permit_mynetworks, reject smtpd_enforce_tls = no smtpd_helo_required = no smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain,reject_unlisted_recipient, permit_tls_all_clientcerts, permit_sasl_authenticated, permit_mynetworks, permit_mx_backup, reject_unauth_destination, permit smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_local_domain = $mydomain smtpd_sasl_security_options = noplaintext,noanonymous smtpd_sasl_tls_security_options = noanonymous smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_tls_CAfile = /etc/ssl/certs/ucla-math.crt smtpd_tls_CApath = /etc/ssl/certs smtpd_tls_ask_ccert = yes smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ssl/hostcerts/host.crt smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem smtpd_tls_key_file = /etc/ssl/private/host.key smtpd_tls_loglevel = 0 smtpd_tls_received_header = yes smtpd_tls_req_ccert = no smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes soft_bounce = no strict_rfc821_envelopes = no tls_random_exchange_name = /var/lib/postfix/prng_exch tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 550
Re: Unknown senders and spam
Alex: > Hi, > > > maps_rbl_domains (default: empty) > > > > ? ?Obsolete feature: use the reject_rbl_client feature instead. > > Yes, that was why I was asking. It's a really old version of postfix > I'm still using on this host for now, until I can migrate to an > entirely new server and at the same time keep this one running. > > I just wanted to confirm that this feature, or an equivalent, isn't > available in old versions of postfix? If in doubt read the documentation. man 5 postconf ... reject_rbl_client rbl_domain=d.d.d.d ... This feature is available in Postfix 2.0 and later.
Re: Unknown senders and spam
Note: just before sending this I went back to read the rest of the thread, wherein I see that you're using a pre-2.0 Postfix. Some of my advice below is thereby not relevant to this host, namely, the suggestion to use newer syntax and the newer restriction, reject_unknown_reverse_client_hostname. IMO that would be worth an upgrade. On Sun, Apr 18, 2010 at 02:19:15PM -0400, Alex wrote re: reject_unknown_client_hostname : > Is it common practice to have that restriction in a production > environment? Recently I had a failure of reverse DNS at my colo provider. It went some days before I was aware of the issue (it's a small site and I don't monitor the logs.) When I discovered the issue, I found a lot of mail in the queue, but few outright 5xx rejections had been done. Temporary rejections were occurring from numerous large providers, including Gmail, AOL, Yahoo, and Comcast. I temporarily shut down outbound mail and set up a relayhost while the provider fixed the rDNS issues (my PTR query was returning NXDOMAIN during this time.) Note, from the documentation suggested for you, that there are different conditions which trigger reject_unknown_client_hostname. Mine was lack of PTR, which also triggers the less aggressive reject_unknown_reverse_client_hostname restriction. This is fairly common, and IMO, a pretty likely spam sign. Given my experience, I think it is time to use reject_unknown_reverse_client_hostname. At least you know you're not alone in enforcing that policy. Another condition is when there is a PTR, but the name given does not resolve. This, too, is not unusual. But IMO it's probably less likely a spam sign. You might block a few sites where the understanding of DNS and mail issues is not so strong. A third condition is when the PTR name resolves to a different IP address. This is arguably the "worst" case, because it could mean that a spammer or scammer/spammer is trying to spoof a legitimate domain. IRL this is not usually the case; more likely just another poorly managed site. Most spam is going to come from malware-infected Windows machines or other compromised hosts being used as a zombie. There are many useful strategies in dealing with those, including Spamhaus Zen and reject_non_fqdn_helo_hostname. reject_unknown_reverse_client_hostname is also very effective, as I think some ISPs might deliberately not provide reverse DNS for their dynamic ranges. Most of the rest of it is going to come from large "snowshoe" ranges. These networks will typically have perfect FCrDNS for every IP address. > It appears to be the third case here, that the name->address mapping > does not match the client IP address. Could this be from a legitimate > cause, or typically intentionally to be evasive? > > Could it be found in a legitimate dynamic environment, such as at an ISP? > > Is there a way to log these specific failures so I can get a better > idea of under what circumstances they occur in my environment? > > I'm currently rejecting the following, in this order: > > reject_non_fqdn_sender, Reasonable, not going to block much; not likely to block any spam, but the mail it blocks is mail you should not accept anyway. > reject_non_fqdn_recipient, Harmless but useless. > reject_unknown_sender_domain, ditto reject_non_fqdn_sender > reject_unknown_recipient_domain, Harmless but useless. Who is giving you invalid recipients at this point? > reject_unauth_pipelining, Might catch some zombies. > reject_invalid_hostname, Old syntax, ditto reject_non_fqdn_sender except might also catch a zombie here and there. > reject_non_fqdn_hostname, Old syntax, very effective against zombies, safe and reasonable. > reject_unauth_destination, (Necessary, no comment needed.) > reject_maps_rbl, Old syntax, could be good or could be disastrous. Switch to the "new" syntax (new since Postfix 2.0 IIRC) of "reject_rbl_client zone.name". At this point I'm only using zen.spamhaus.org, but I might be adding spameatingmonkey. Most important advice regarding DNSBLs is to be familiar with their policies and aware of their status. Given the dominance of ancient syntax in your restrictions, I wouldn't be surprised to see some dead lists among your maps_rbl_domains. :) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Receiving bounce messages back to local-host
On 4/18/2010 4:40 PM, groups wrote: Noel Jones wrote, On 04/18/2010 04:20 PM: On 4/18/2010 4:16 PM, groups wrote: Postfix logs help you know what happened to a particular message. Look in your logs for bounces (sender=<>) arriving from your relayhost, and see what postfix does with it. No need to wonder where they went. -- Noel Jones A lot of the send only hosts have only an IP (not in DNS) Look in the logs for the IP to find associated QUEUEIDs. Apr 18 16:01:24 mailhost postfix/qmgr[3283]: 5BE9956799: from=<>, size=89424, nrcpt=1 (queue active) Look in the logs for other entries with that same QUEUEID 5BE9956799 to see other information associated with that transaction. only 1 entry per transaction ID.. notthing in /var/spool/postfix ... ok.. and found something interesting.. Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 04C2A56799: from=<>, size=83199, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 2B54756799: from=<>, size=83614, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 4D99856799: from=<>, size=84029, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 7B1F756799: from=<>, size=8, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 9BD4456799: from=<>, size=84859, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: BF6DC56799: from=<>, size=85274, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: E147056799: from=<>, size=85689, nrcpt=1 (queue active) All have the same invalid recipient.. These show the sender and number of recipients = 1; the recipient address is listed in a different log line. That seems like an awful lot of bounces in a short period of time. Sending lots of mail to undeliverable addresses is a red flag that something is wrong -- such as a badly outdated mail list, or a compromised machine spewing spam. One of your tasks is to investigate why there are so many bounces, and find a way to reduce them. Sending large amounts of undeliverable mail will have a bad effect on your server's reputation and may eventually lead to blacklisting. Almost looks like it is "ping-ponging" back and forth between the *master-relay* and my relay.. Messages with the null sender "<>" are never bounced, they must be delivered or discarded. Bounces are always sent with the null sender. This prevents bounces from ever looping (except in rare cases of stupid user tricks such as a .forward that rewrites <> to something else -- don't do that). Further information about those messages can be found in the logs. I have seen this invalid recipient on the old Sendmail box.. and it ended up in my queue then expires.. (the sender host has been out of the office when I tried to contact them) so it looks like I have something not right.. there is nothing in mailq.. Charles You need to examine the log further. If there's a problem, postfix will likely tell you what it is, or at least give you a better idea of where to look. Postfix generates several log lines for each message. You need to look at *all* the lines with the same QUEUEID to see what happened to a message. Logs for a single message look something like this below (with my comments). Because postfix can process many messages in parallel, logs for a single message may be separated by a considerable number of unrelated log entries. There may be more or fewer entries depending on what happens with a transaction, but this is fairly typical. Apr 18 00:00:20 mgate2 postfix/smtpd[91955]: connect from private.webmail.example.org[192.168.70.47] to smtpd (client connected; the hostname and IP are logged) Apr 18 00:00:20 mgate2 postfix/smtpd[91955]: 1A2C779788F: client=private.webmail.example.org[192.168.70.47] (the QUEUEID "1A2C779788F" is assigned. That means there was at least one recipient accepted and a queue file was created. Future lines pertaining to this specific message will include this same QUEUEID) Apr 18 00:00:20 mgate2 postfix/cleanup[92028]: 1A2C779788F: message-id=<1100418.aa11...@example.org> (the Message-id: header is logged. This is a helpful unique message identifier when searching the logs for a specific message.) Apr 18 00:00:20 mgate2 postfix/qmgr[95868]: 1A2C779788F: from=<>, size=382, nrcpt=1 (queue active) (envelope sender, size, number of recipients, which queue it's assigned to) Apr 18 00:00:20 mgate2 postfix/smtpd[91955]: disconnect from private.webmail.vbhcs.org[192.168.70.47] (postfix has disconnected from the client. This line can be related to the "connect" line above by the smtpd process id, in this case "91955") Apr 18 00:00:20 mgate2 postfix/local[94393]: 1A2C779788F: to=, relay=local, delay=0.11, delays=0.05 /0.03/0/0.02, dsn=2.0.0, status=sent (delivered to maildir) (the mail was delivered to a local user) Apr 18 00:00:20 mgate2 postfix/qmgr[95868]: 1A2C779788F: removed (postfix completed this message, and remov
Re: Unknown senders and spam
Hi, > reject_unknown_client_hostname : >> Is it common practice to have that restriction in a production >> environment? [...] > Note, from the documentation suggested for you, that there are > different conditions which trigger reject_unknown_client_hostname. > Mine was lack of PTR, which also triggers the less aggressive > reject_unknown_reverse_client_hostname restriction. This is fairly > common, and IMO, a pretty likely spam sign. Given my experience, I > think it is time to use reject_unknown_reverse_client_hostname. At > least you know you're not alone in enforcing that policy. In this thread from just last June, the consensus was that it still rejected too much mail: http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html It was only from a few users, but wonder what their experience is almost a year later. In any case, I can't even test it, because apparently my postfix doesn't even understand "warn_if_reject". It silently ignored it, and silently stopped accepting mail until I realized there were two hundred messages in the queue after five minutes on a Sunday :-) Most of it was spam anyway :-) > Most spam is going to come from malware-infected Windows machines or > other compromised hosts being used as a zombie. There are many useful > strategies in dealing with those, including Spamhaus Zen and > reject_non_fqdn_helo_hostname. reject_unknown_reverse_client_hostname > is also very effective, as I think some ISPs might deliberately not > provide reverse DNS for their dynamic ranges. > > Most of the rest of it is going to come from large "snowshoe" ranges. > These networks will typically have perfect FCrDNS for every IP > address. and you're saying the reject_unknown_reverse_client_hostname wouldn't help here, if I understand correctly? >> reject_maps_rbl, > > Old syntax, could be good or could be disastrous. Switch to the "new" > syntax (new since Postfix 2.0 IIRC) of "reject_rbl_client zone.name". Do you have any (postfix v2) restrictions that we haven't yet seen here that would be worth sharing for this topic? > At this point I'm only using zen.spamhaus.org, but I might be adding > spameatingmonkey. Most important advice regarding DNSBLs is to be I'm also using just those, and also considering bb.barracudanetworks.org to reject at SMTP time. How do you think it compares? > familiar with their policies and aware of their status. Given the > dominance of ancient syntax in your restrictions, I wouldn't be > surprised to see some dead lists among your maps_rbl_domains. :) I'm somewhat familiar with those, but do you know of a location that describes the policies of the top five URI and DNS blocklists in one place? That would sure be useful. Thanks again for helping me to understand. Certainly upgrading is a top priority. Best regards, Alex
Re: Postfix compile on OS X 10.6
On Apr 14, 2010, at 7:52 AM, Jim Wright wrote: > On Apr 12, 2010, at 11:32 PM, Jim Wright wrote: > >> I'm setting up a new server completely from scratch on Snow Leopard, Mac OS >> X 10.6.3, trying to compile Postfix 2.7. During make, I get this: >> >> In file included from dns_lookup.c:152: >> dns.h:23:29: error: nameser8_compat.h: No such file or directory >> make: *** [dns_lookup.o] Error 1 >> make: *** [update] Error 1 >> >> >> I haven't seen this come up on the list yet, so I wanted to report this >> here. A google search found a suggested fix, in /src/util/sys_defs.h, the >> following line should be commented out: >> >> #define RESOLVE_H_NEEDS_NAMESER8_COMPAT_H >> >> With this line commented out, I'm able to get a good build. My question is, >> should I be worried about screwing something up having this line commented >> out? I'm sure it's there for a reason. (grin) > > I've dug a bit more into this one. Mac OS X 10.6 no longer has an include > file named nameser8_compat.h. The equivalent file seems to be > arpa/nameser_compat.h. Updating the dns.h file (line 23) to include this > file instead results in a good build. It may be another day or so before I'm > able to put this server online to test. Just an FYI that this change does seem to be stable, I'm not noticing any errors running this build on Snow Leopard.
Re: Unknown senders and spam
On 4/18/2010 9:56 PM, /dev/rob0 wrote: reject_unauth_pipelining, Might catch some zombies. Note that with older postfix (postfix < 2.6 IIRC) reject_unauth_pipelining must be used in smtpd_data_restrictions to be effective. It won't break anything in smtpd_recipient_restrictions, but it won't block anything either. reject_maps_rbl, Old syntax, could be good or could be disastrous. Switch to the "new" syntax (new since Postfix 2.0 IIRC) of "reject_rbl_client zone.name". Using the old syntax is harmless[1] and still works; the new syntax was introduced for more flexibility. [1] harmless until some undefined point in the future when it's removed and no longer recognized. -- Noel Jones
Re: Unknown senders and spam
On 4/18/2010 10:24 PM, Alex wrote: Note, from the documentation suggested for you, that there are different conditions which trigger reject_unknown_client_hostname. Mine was lack of PTR, which also triggers the less aggressive reject_unknown_reverse_client_hostname restriction. This is fairly common, and IMO, a pretty likely spam sign. Given my experience, I think it is time to use reject_unknown_reverse_client_hostname. At least you know you're not alone in enforcing that policy. In this thread from just last June, the consensus was that it still rejected too much mail: http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html It was only from a few users, but wonder what their experience is almost a year later. Yes, reject_unknown_client_hostname is still too strict for us. And we're very strict! But the cool thing about local email policy is that you get to decide for yourself what's too strict. Some people do use reject_unknown_client_hostname, but my impression it that they are mostly home/hobbyist/very small business. Rule of thumb: the more people you have to answer to, the less strict you must be. In any case, I can't even test it, because apparently my postfix doesn't even understand "warn_if_reject". It silently ignored it, and silently stopped accepting mail until I realized there were two hundred messages in the queue after five minutes on a Sunday :-) Most of it was spam anyway :-) The "warn_if_reject" feature predates "reject_unauth_pipelining", which you seem to be using successfully. I strongly suspect there was some other error -- probably a simple typo in your config -- that kept warn_if_reject from working for you. From the (ancient) HISTORY file: 20011105 ... Feature: put "warn_if_reject" before an smtpd restriction, and that restriction logs warnings without rejecting mail. [...] 20020905 Feature: "smtpd_data_restrictions = reject_unauth_pipelining" blocks mail from SMTP clients that send message content before Postfix has replied to the DATA command. File: -- Noel Jones
Re: Unknown senders and spam
Hi, > Note that with older postfix (postfix < 2.6 IIRC) reject_unauth_pipelining > must be used in smtpd_data_restrictions to be effective. It won't break > anything in smtpd_recipient_restrictions, but it won't block anything > either. Ah, great. I've moved it and it appears to be working (at least not complaining). >> Old syntax, could be good or could be disastrous. Switch to the "new" >> syntax (new since Postfix 2.0 IIRC) of "reject_rbl_client zone.name". > > Using the old syntax is harmless[1] and still works; the new syntax was > introduced for more flexibility. Will reject_rhsbl_sender and reject_rhsbl_client work in old versions? Thanks for being helpful and tolerant when I should be flamed for using such an old version. Thanks, Alex
Re: Unknown senders and spam
Hi, >> http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html >> >> It was only from a few users, but wonder what their experience is >> almost a year later. > > Yes, reject_unknown_client_hostname is still too strict for us. And we're > very strict! Good to know. I also don't think I can easily make such a change in my environment. > The "warn_if_reject" feature predates "reject_unauth_pipelining", which you > seem to be using successfully. I strongly suspect there was some other > error -- probably a simple typo in your config -- that kept warn_if_reject > from working for you. I'm trying to do: warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net But it appears that's only available in later versions, so I've tried this, and it also doesn't work: warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net > 20020905 > > Feature: "smtpd_data_restrictions = reject_unauth_pipelining" It looks like I have a big project ahead of me to upgrade. What kind of process is involved with going from such an old version to the current, independent of all the other software? Thanks, Alex
Re: Unknown senders and spam
Alex(mysqlstud...@gmail.com)@Mon, Apr 19, 2010 at 01:11:01AM -0400: > Hi, > > >> http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html > >> > >> It was only from a few users, but wonder what their experience is > >> almost a year later. > > > > Yes, reject_unknown_client_hostname is still too strict for us. And we're > > very strict! > > Good to know. I also don't think I can easily make such a change in my > environment. > > > The "warn_if_reject" feature predates "reject_unauth_pipelining", which you > > seem to be using successfully. I strongly suspect there was some other > > error -- probably a simple typo in your config -- that kept warn_if_reject > > from working for you. > > I'm trying to do: > > warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net > > But it appears that's only available in later versions, so I've tried > this, and it also doesn't work: > > warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net You probably want: warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net without the "=". -- Bill Weiss We will not prove this by intimidation and excessive fist waving. [while screaming these lines and frantically waving arms] -- Dr. Max Mintx, Math. Foundations of CS University of Pennsylvania
Re: Unknown senders and spam
Alex a écrit : > Hi, > >>> Is it common practice to have that restriction in a production environment? >>> >>> It appears to be the third case here, that the name->address mapping >>> does not match the client IP address. Could this be from a legitimate >>> cause, or typically intentionally to be evasive? >>> >> since they put their domain name in their HELO (zaphod.chipchaps.com), >> they're not trying to evade anything. > > Yes, I guess they would have been rejected as a result of my helo checks. > >> you could try >> >>check_client_access hash:/etc/postfix/access_unknown >> >> >> smtpd_restriction_classes = >>... >>policy_strong >> >> policy_strong = >>reject_rbl_client bb.barracudacentral.org > > Is it possible to use maps_rbl_domains instead of reject_rbl_client > here? with maps_rbl_domains, you can't specify which list to check in different places. since you're already using it in the "general" case, if you add barracuda list, it will apply unconditionally, which is different from my suggestion to call it when the clien is unknown. but if you think barracuda list is safe for you (it's not for me. the corresponding score in spamassassin confirms this for me), you can use it. > It appears this machine has a version of postfix that doesn't > understand reject_rbl_client. > > Thanks again! > Best regards, > Alex
Re: Unknown senders and spam
Alex a écrit : > Hi, > >>> http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html >>> >>> It was only from a few users, but wonder what their experience is >>> almost a year later. >> Yes, reject_unknown_client_hostname is still too strict for us. And we're >> very strict! > > Good to know. I also don't think I can easily make such a change in my > environment. > >> The "warn_if_reject" feature predates "reject_unauth_pipelining", which you >> seem to be using successfully. I strongly suspect there was some other >> error -- probably a simple typo in your config -- that kept warn_if_reject >> from working for you. > > I'm trying to do: > > warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net > wrong syntax. it's warn_if_reject reject_rbl_client $yourlist There's no 'equal' sign. > But it appears that's only available in later versions, so I've tried > this, and it also doesn't work: > > warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net > doubly wrong syntax. besides the '=' sign, reject_rbl_maps doesn't take an argument. >> 20020905 >> >>Feature: "smtpd_data_restrictions = reject_unauth_pipelining" > > It looks like I have a big project ahead of me to upgrade. What kind > of process is involved with going from such an old version to the > current, independent of all the other software? > > Thanks, > Alex
Re: Unknown senders and spam
Hi, >> I'm trying to do: >> >> warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net >> > > wrong syntax. it's > warn_if_reject reject_rbl_client $yourlist > There's no 'equal' sign. $ postfix check postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after attribute name: "warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net" Apr 19 02:35:33 smtp01 postfix[13351]: fatal: /etc/postfix/main.cf, line 700: missing '=' after attribute name: "warn_if_reject reject_maps_rbl backscatter.spameatingmonkey.net" >> But it appears that's only available in later versions, so I've tried >> this, and it also doesn't work: >> >> warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net > > doubly wrong syntax. besides the '=' sign, reject_rbl_maps doesn't take > an argument. Looks like I'm SOL for now? :-) Thanks again, Alex
Re: Unknown senders and spam
Noel Jones put forth on 4/18/2010 10:55 PM: > Yes, reject_unknown_client_hostname is still too strict for us. And > we're very strict! I ran with this for a short while. Had problems with it rejecting Hotmail connections. And these weren't Hotmail user mails beings delivered, but responses to my spam reports coming from the Hotmail abuse dept. Had too many other legit mails refused as well. It didn't stop any more spam here than reject_unknown_reverse_client_hostname so I reverted back to the latter. -- Stan
Mail server responded 5.7.1
In our group we are using suse and Postfix SMTP server. Every thing was fine until last month when we restart our mail server and also firewall. The first problem is that when we use Thunderbird with security and Authentication it is impossible to send a email. we receive this error “Unable to authentication to SMTP server ...”. however , it is possible to send email without Authentication in local network. The second problem is that we can not send email via Thunderbird from outside of our local network. The error is “Mail server responded 5.7.1 ..”. we also have web mail (Squirrelmail) and it works without any problems everywhere. I completely confuse without change anything these problem happen. I was wondering if someone could help me. P.S : I am a beginner in postfix so please tell the solution with details. If you need more information tell me.
Re: Mail server responded 5.7.1
On 04/19/2010 12:53 AM, mohamad rahimi wrote: > a email. we receive this error Unable to authentication to SMTP > server however , it is possible to send email without [...] > The error is Mail server responded > 5.7.1 ... It seems like you are replacing the most important part of the error messages with "..." above. You'll almost certainly want to include the full text of the error messages, as they likely say what is going wrong. You probably also want to look at the logs on the server when this happen. They may have more information on what is failing and why. This is often in /var/log/maillog or /var/log/mail.log on Linux systems. Sean -- Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability signature.asc Description: OpenPGP digital signature
