permit_naked_ip_address vs permit_my_networks OR how to permit naked ip's from everywhere in HELO check
Hi, a short question about the parameter "permit_naked_ip_address": As a client may use his IP for the HELO command ( look at the recent RFC's ), and the usage of permit_naked_ip_address DOES NOT turn the postfix into an open relay, which way we should use permit_my_networks to allow IP's in the HELO? Why is permit_naked_ip_address deprecated this way? Sincerely, -------- Thomas Berger - Certified Linux/Cisco Networking Engineer - BOREUS Rechenzentrum GmbH Zur Schwedenschanze 2 D - 18435 Stralsund Germany Phone:+49 (0) 38 31 - 36 76 415 Fax: +49 (0) 38 31 - 36 76 615 eMail: t...@boreus.de Internet: http://www.boreus.de/ -- Geschäftsführer: André Jahns, Holger Lebrecht Handelsregister: Amtsgericht Stralsund HRB 5750 Sitz der Gesellschaft: Stralsund
Re: permit_naked_ip_address vs permit_my_networks OR how to permit naked ip's from everywhere in HELO check
> the RFC's are nice but in this days everybody who maintains a mailserver > has to look that HELO is a vild hostname which resolves in both directions > or has not to wonder if his mails are dropped! > > not all things that are not explicit forbidden are well behavior! That's right, but does not solve our problem. We host mailsystems for big customers. One of them is a provider for a special hotel platform. As they get mails from around the world, and the mails are something like reservation mails, we need to accept them. We alredy deny everything not rfc conform, or better, we WANT to deny anything NOT rfc conform. So, is there any clean solution for this?
Re: permit_naked_ip_address vs permit_my_networks OR how to permit naked ip's from everywhere in HELO check [SOLVED]
> what problem are you trying to solve? > the default config doesn't reject naked IPs in helo. I descriped the reason why we have to accept such naked ips in my last mail. To the background: The inbound mailsystem for one of our customers was on heavy load around the clock. So we set helo_ and client_restrictions to some usefull values. We have to keep as close to the rfc's as possible, as mails are money in this case. But there are some systems, the most are integrated systems with dial up systems, sending mails with naked_ip in the helo. We have to accept them, but don't want to accept the whole dynamic ip range, as that would be a security risk. but as mentioned right now by some other on the list, the ip must be enclosed by [], so forget this topic =) And by the way: a permit_naked_ip_address in helo restrictions would only lead to an open relay, if the sender_restrictions are garbage, and this way, we will get an open relay anyway. We have tested this with a few different postfix versions today.
Re: Another open source anti spam framework
Hi Ulrich, after a bit of reading on the project site, there is one thing, i see a little bit critical: On the "about" page there is a "Simple Setup" example. In this you describe: - Postfix accepts and receives (or rejects) the mail and delivers it to the Detective. - The Detective might reject the mail, which will force postfix to bounce it, or passes it again and re-inject it into another postfix process. I i understand this right, postfix would bounce the mail after it was accepted for delivery. This would cause backscatter. And a backscattering spamfilter is as bad as a real spamserver. Greetings from Germany, -------- Thomas Berger - Certified Linux/Cisco Networking Engineer - BOREUS Rechenzentrum GmbH Zur Schwedenschanze 2 D - 18435 Stralsund Germany Phone:+49 (0) 38 31 - 36 76 415 Fax: +49 (0) 38 31 - 36 76 615 eMail: t...@boreus.de Internet: http://www.boreus.de/ -- Geschäftsführer: André Jahns, Holger Lebrecht Handelsregister: Amtsgericht Stralsund HRB 5750 Sitz der Gesellschaft: Stralsund Am Mittwoch, 25. Mai 2011, 10:20:21 schrieb Ulrich Kautz: > Hello all > > i wrote another anti SPAM framework called Decency, which works perfectly > with Postfix. It's based on Perl POE and Mouse and is highly modularized / > componentized. Since something last week, it has earned it's own website: > http://www.decency-antispam.org > Also on github: > https://github.com/ukautz/decency > The CPAN release is heavily outdated and will be renewed at the end of this > month. > > In short what it does: > * It has a policy server, called Doorman, implementing techniques such as > Greylisting, Geo Weighting, DNSBLs, Honeypot building, SPF and so on. > * The second component is a content filter, called Detective, which > implements third party filters (CRM114, DSPAM, ..), virus filters (for now: > ClamAV) and also performs internal filtering, such as DKIM, deeper DNSBLs checks (Received-header) and also can act as an Archiving facility. > * Its modular build, everybody can extend it. > * Designed for single mail filter boxes as well as distributed structures. > * Open source. > * Simple configuration (imho). > * More on the mentioned website.. > > I used it in production for about half a year. Currently it's going towards > public stable version 0.2.0. > > Any feedback, critic, help, whatever is welcome. > > Greets from Berlin > Ulrich > signature.asc Description: This is a digitally signed message part.
Re: Relay Access Denied
Hi Kurniawan, this is the default. Please have a look at the great docs: http://www.postfix.org/SMTPD_ACCESS_README.html Greetings, Thomas Am Freitag, 27. Mai 2011, 09:40:24 schrieb Kurniawan Junaidy: > Hi folks, > > I am not able to send email through my postfix server by using any > external ip, but ok from my internal ip. The file says about Relay > Access Denied 554 5.7.1. How to fix this? > > Thanks. > > regards, > Kurniawan signature.asc Description: This is a digitally signed message part.
Re: Join my network on LinkedIn
popcorn? Anybody? Am Freitag, 27. Mai 2011, 13:49:02 schrieb Thijssen: > On Fri, May 27, 2011 at 00:08, wrote: > > On Fri, 27 May 2011 00:03:26 +0200, Jeroen Geilman wrote: > >> > >> On 05/26/2011 11:58 PM, Reindl Harald wrote: > >>> > >>> can somebody please remove the idiots from LinkedIn from > >>> mailing-lists? > >>> > >> > >> s/from LinkedIn// > > > > > > go back home new guy > > Wow, what a positive productive answer from the typical spoiled rotten > american. You do realize that 5% of you US-citizen (ab)use 26% of the > planet's resources? (I can post a reliable source for that if you > want) > So, you should understand that 'new guys' and those who aren't at > 'home' where you live should be proud to not be from the US, and YOU > should be ashamed of your 'home' and what it apparently stands for. > Jeroen posted a brilliant solution to the problem, be thankful that he > did and shut your overconsuming piehole. Try some modesty next time. > > J. > > http://www.youtube.com/watch?v=unGiO9mKUDM signature.asc Description: This is a digitally signed message part.
Redirect mails to virtual address
Hi all,
in our current configuration, we have one postfix system, in front of some
other mailservers.
We check the recipient address of incoming mails at the first system, and could
reject the mail there, if send to an unknown user.
But if the users mailbox is full, we would send backscatter.
Now we want to redirect Bounces, send to an external system to one of our
virtual users.
But, as the virtual address expansion is already done, until we pass the
smtpd_reciepient_restrictions, we get an "user unknown" error.
Is there another solution, to redirect mails from <> based on the recipient
address?
I attached the output of postconf to this mail, here are the relevant ports of
the logfile:
May 31 15:16:32 christel postfix/smtpd[3890]: NOQUEUE: redirect: RCPT from
bor-hsc.user.boreus.de[10.114.100.48]: :
Recipient address triggers REDIRECT
postmas...@boreus.de; from=<> to= proto=SMTP
May 31 15:16:39 christel postfix/virtual[3900]: F2A382AD89:
to=, orig_to=,
relay=virtual, delay=17, delays=17/0/0/0, dsn=5.1.1, status=bounced
(unknown user: "postmas...@boreus.de")
postmas...@boreus.de is a valid virtual address, mapped to mutliple internal
recipients. As we have only virtual domains on this mailsystem, there is no way
to send to a local user.
Greetings from Germany,
--------
Thomas Berger
- Certified Linux/Cisco Networking Engineer -
BOREUS Rechenzentrum GmbH
Zur Schwedenschanze 2
D - 18435 Stralsund
Germany
Phone:+49 (0) 38 31 - 36 76 415
Fax: +49 (0) 38 31 - 36 76 615
eMail: t...@boreus.de
Internet: http://www.boreus.de/
--
Geschäftsführer: André Jahns, Holger Lebrecht
Handelsregister: Amtsgericht Stralsund HRB 5750
Sitz der Gesellschaft: Stralsund2bounce_notice_recipient = postmaster
access_map_reject_code = 554
address_verify_default_transport = $default_transport
address_verify_local_transport = $local_transport
address_verify_map =
address_verify_negative_cache = yes
address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 3h
address_verify_poll_count = 3
address_verify_poll_delay = 3s
address_verify_positive_expire_time = 31d
address_verify_positive_refresh_time = 7d
address_verify_relay_transport = $relay_transport
address_verify_relayhost = $relayhost
address_verify_sender = $double_bounce_sender
address_verify_sender_dependent_relayhost_maps =
$sender_dependent_relayhost_maps
address_verify_service_name = verify
address_verify_transport_maps = $transport_maps
address_verify_virtual_transport = $virtual_transport
alias_database = hash:/etc/aliases
alias_maps = mysql:/etc/postfix/mysql-aliases.cf
allow_mail_to_commands = alias, forward
allow_mail_to_files = alias, forward
allow_min_user = no
allow_percent_hack = yes
allow_untrusted_routing = no
alternate_config_directories =
always_bcc =
anvil_rate_time_unit = 60s
anvil_status_update_time = 600s
append_at_myorigin = yes
append_dot_mydomain = yes
application_event_drain_time = 100s
authorized_flush_users = static:anyone
authorized_mailq_users = static:anyone
authorized_submit_users = static:anyone
backwards_bounce_logfile_compatibility = yes
berkeley_db_create_buffer_size = 16777216
berkeley_db_read_buffer_size = 131072
best_mx_transport =
biff = yes
body_checks =
body_checks_size_limit = 51200
bounce_notice_recipient = postmaster
bounce_queue_lifetime = 5d
bounce_service_name = bounce
bounce_size_limit = 5
bounce_template_file =
broken_sasl_auth_clients = yes
canonical_classes = envelope_sender, envelope_recipient, header_sender,
header_recipient
canonical_maps =
cleanup_service_name = cleanup
command_directory = /usr/sbin
command_execution_directory =
command_expansion_filter =
1234567890!@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
command_time_limit = 1000s
config_directory = /etc/postfix
connection_cache_protocol_timeout = 5s
connection_cache_service_name = scache
connection_cache_status_update_time = 600s
connection_cache_ttl_limit = 2s
content_filter =
cyrus_sasl_config_path =
daemon_directory = /usr/lib/postfix
daemon_timeout = 18000s
data_directory = /var/lib/postfix
debug_peer_level = 2
debug_peer_list =
default_database_type = hash
default_delivery_slot_cost = 5
default_delivery_slot_discount = 50
default_delivery_slot_loan = 3
default_destination_concurrency_failed_cohort_limit = 1
default_destination_concurrency_limit = 20
default_destination_concurrency_negative_feedback = 1
default_destination_concurrency_positive_feedback = 1
default_destination_rate_delay = 0s
default_destination_recipient_limit = 50
default_extra_recipient_limit = 1000
default_minimum_delivery_slots = 3
default_privs = nobody
default_process_limit = 500
default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what]
blocked using $rbl_domain${rbl_reason?; $rbl_reason}
Re: Redirect mails to virtual address
Thanks for the replies. I forgotten some details in my last mail: Our current configuration looks like this: [outter-postfix] (MX, Spamfilter, virus scanner ...) <=> [inner-postfix] (expands the virtual recipients, delivers mails to different internel MTA's) <=> Exchange Server (holds the user mailboxes) Am Dienstag, 31. Mai 2011, 16:15:38 schrieb /dev/rob0: > The "right" solution is to have the recipient address checking > process also check for the "full mailbox" condition, or better yet, > use a check_recipient_access lookup which returns a proper reject > message for these full mailboxes. We could not figure out right now how to do that with an Exchange Server as mailstorage. Maybe someone on this list knows how to setup this correct? > > Now we want to redirect Bounces, send to an external system to one > > of our virtual users. > > This is broken. Although you're rightly thinking about minimizing > backscatter, you may be causing loss of real mail. As we only redirect the mails and don't drop them, and thats only effects outgoing mail, we would never loose some real mails. > Please note that what is needed is "postconf -n". It's possible that > I missed something relevant in all of that, which I did not attempt > to read. Done, i have attached a new output to this mail. > So I guess you are saying it is a virtual ALIAS. Here it failed to be > delivered as a virtual MAILBOX. If you have receive_override_options > set with no_address_mappings, you can't deliver to a virtual alias at > this point. We don't have this set anywhere, there are no override options, we use virtual aliases here since a few years, without any problem. > > As we have only virtual domains on this > > mailsystem, there is no way to send to a local user. > > > receive_override_options = > > > smtpd_client_restrictions = permit_mynetworks, > > permit_sasl_authenticated, reject > > (This is not suitable for a MX host.) > This is not an MX host, this is just an internal relay. > > smtpd_data_restrictions = > > > smtpd_helo_restrictions = > > > smtpd_recipient_restrictions = check_sender_access > > hash:/etc/postfix/check_bounce_sender, permit_mynetworks, > > permit_sasl_authenticated, reject_unauth_destination > > > smtpd_sender_restrictions = mysql:/etc/postfix/mysql-sender_restrictions.cf > > No check_recipient_access lookup exists in the above. Here the relevant parts from the config and the maps: /etc/postfix/main.cf: smtpd_restriction_classes = check_bounce_recipient check_bounce_recipient= check_recipient_access pcre:/etc/postfix/bounce_recipients smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/check_bounce_sender /etc/postfix/check_bounce_sender: <> check_bounce_recipient MAILER-DAEMON@ check_bounce_recipient /etc/postfix/bounce_recipients: /(^|\.)boreus\.de$/ DUNNO /./REDIRECT postmas...@boreus.de > What you are telling us is that virtual_alias_maps were not checked, > but no evidence to that effect was shown. ~ # postmap -q postmas...@boreus.de mysql:/etc/postfix/mysql-virtual.cf unix-ad...@boreus.de > > virtual_mailbox_domains = > > mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf > > boreus.de is found here, in virtual_mailbox_domains > > > virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-maps.cf > > postmas...@boreus.de is NOT found here. Thats right, as not every virtual user is in the same system. We have a few system accounts, used for bounce back mgmt and more, but thats a rare case. > Go back to the right solution, above. Figure out a way to check for > and populate a list of addresses with "full" mailboxes. Then consult > that list as a check_recipient_access lookup. As we didn't found any informations about doing that in the exchange docs or on the net, that seems impossible at the moment :( alias_maps = mysql:/etc/postfix/mysql-aliases.cf 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 = 20 default_process_limit = 500 home_mailbox = .maildir/ inet_interfaces = all local_destination_concurrency_limit = 5 local_recipient_maps = local_transport = local luser_relay = quarant...@mydatacenter.de mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 19631488 minimal_backoff_time = 600 mydestination = $myhostname, mysql:/etc/postfix/mysql-mydestination.cf myhostname = mail.boreus.de mynetworks = 127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16 80.154.16.8/32 80.154.16.6/32 85.199.64.8/32 195.50.177.8/32 195.50.176.6/32 mynetworks_style = host myorigin = /etc/mailname newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix/README_FILES recipient_delimiter = + relocated_maps = mysql:/etc/postfix/mysql-relocated.c
Re: howto limit sasl auth ipranges in postfix?
> Benny Pedersen: > > since i never travel outside my own country i have desided to limit based > > on ip to not have sasl on whole ipv4 and now ipv6 ip ranges, my question > > is, is enough to remove starttls in port 25 to disable sasl for this > > clients ? > > > > there is properly better ways to make it, i just need to know them so > > You can use smtpd_discard_ehlo_keyword_address_maps to disable > AUTH by IP address. With this, the Postfix SMTP server will not > announce AUTH support and will not accept AUTH commands. > Another solution: - Use the submission port for authenticated clients - only allow server2server communication on port 25 - use a firewall to block incomming traffic to the submission port (- use a firewall to block all traffic from dynamic ipranges to port 25) Greetings Thomas Berger signature.asc Description: This is a digitally signed message part.
Re: No Netflix, lost connection after CONNECT
> I must confess that the tcpdump output is over my head. Any help would be > appreciated. I see a lot of checksums marked bad and "incorrect" but I have > no idea how to fix it. > Justin T Q 11.1: Why am I seeing lots of packets with incorrect TCP checksums? A: If the packets that have incorrect TCP checksums are all being sent by the machine on which Wireshark is running, this is probably because the network interface on which you're capturing does TCP checksum offloading. That means that the TCP checksum is added to the packet by the network interface, not by the OS's TCP/IP stack; when capturing on an interface, packets being sent by the host on which you're capturing are directly handed to the capture interface by the OS, which means that they are handed to the capture interface without a TCP checksum being added to them. The only way to prevent this from happening would be to disable TCP checksum offloading, but 1. that might not even be possible on some OSes; 2. that could reduce networking performance significantly. Source: http://www.wireshark.org/faq.html#q11.1 This is not a real problem, so you could use `tcpdump -K` to disable checksums. Greetings Thomas signature.asc Description: This is a digitally signed message part.
Re: Request For Port 587
Am Donnerstag, 18. August 2011, 15:23:28 schrieb Jeroen Geilman: > On 2011-08-18 14:59, Reindl Harald wrote: > > > 587 is AUTHENTICATED submission > > > Says who ? Port 587 is AUTHORIZED submission, NOT AUTHENTICATED. A limitation to a local network ist also a kind of authorization. -------- Thomas Berger - Certified Linux/Cisco Networking Engineer - BOREUS Rechenzentrum GmbH Zur Schwedenschanze 2 D - 18435 Stralsund Germany Phone:+49 (0) 38 31 - 36 76 415 Fax: +49 (0) 38 31 - 36 76 615 eMail: t...@boreus.de Internet: http://www.boreus.de/ -- Geschäftsführer: André Jahns, Holger Lebrecht Handelsregister: Amtsgericht Stralsund HRB 5750 Sitz der Gesellschaft: Stralsund
