Postfix - antispam and relay package
-
If you need TLS Config you have to put the following into the "custom main.cf options" Field:
# 20141006 Add TLS # # SMTPD # smtpd_tls_cert_file = /cf/conf/cert.crt smtpd_tls_key_file = /cf/conf/cert.key smtpd_tls_CAfile = /etc/ssl/cert.pem smtpd_tls_security_level = may # SMTP Client smtp_tls_security_level = may smtp_tls_CAfile = /etc/ssl/cert.pem # SSL-Certificate - Generate logfile entries # smtpd_tls_received_header = yes smtp_tls_loglevel = 1 smtpd_tls_loglevel = 1You need to upload the Cert Files to /cf/conf.
I hope this path is upgrade-save, I couldn't test it yet.Maybe someday we can use the Cert Manager Certs of pfSense in Postfix Forwarder Package? ;)
Best regards,
Peter -
What am I doing wrong.
I found my first issue - my port 25 was still NAT'd …
However I now have another issue users in the list of 'custom valid recipients' are getting bounced - the Postfix is saying that the 'recipient address' is rejected, unverified address.
postfix/smtpd[17570]: NOQUEUE: reject: RCPT from mail-qg0-f52.google.com[209.85.192.52]: 450 4.1.1 <@.co.uk>: Recipient address rejected: unverified address: connect to ...[...]:25: Operation timed out; from=*******@gmail.com to=<@.co.uk> proto=ESMTP helo= <mail-qg0-f52.google.com>why ? (there are no indications on the mail server that postfix has even tried)</mail-qg0-f52.google.com>
-
What am I doing wrong.
I found my first issue - my port 25 was still NAT'd …
However I now have another issue users in the list of 'custom valid recipients' are getting bounced - the Postfix is saying that the 'recipient address' is rejected, unverified address.
postfix/smtpd[17570]: NOQUEUE: reject: RCPT from mail-qg0-f52.google.com[209.85.192.52]: 450 4.1.1 <@.co.uk>: Recipient address rejected: unverified address: connect to ...[...]:25: Operation timed out; from=*******@gmail.com to=<@.co.uk> proto=ESMTP helo= <mail-qg0-f52.google.com>why ? (there are no indications on the mail server that postfix has even tried)</mail-qg0-f52.google.com>
Check in Postfix > View config > relay_recipients if you can see your recipients get bounced are in there or not, if not you need to check the Valid recipients config in the recipients tab.
Your server should just accept mail for valid recipients, which makes pretty sense.
-
No trace of a bounce there, IP address is correct, authentication is needed only for sending.
I run two domains, have one public IP to which the public DNS points for both domains, I NAT these to two different IP addresses (internal).
Everything works fine if I go back to NAT'ing port 25 to the mail server directly.
I have the two domains with their respective internal IP address's listed on the domain tab, the user is defined in the 'custom recipients' using the format
user@domain.co.uk OK
I use no wildcards each 'valid' user has an entry.
I use a NAT rule to put port 25 onto 127.0.0.1 and them monitor loopback with Postfix, clearly postfix is receiving the message. I do have an internal DNS server, pFSense is configured to look at it and NOT a public DNS box, the domains resolve correctly to the public IP address - NOTE they DO NOT resolve to the internal IP address's and nor should they, resolving to the correct public IP address IS correct - the domain tab is explicit on the IP address to send mail to. The ... is actually the correct internal IP address for the email address so I don't think it is DNS related anyway.
The messages say that they timed out but my mail server doesn't even log a connection attempt, I have read and read this thread and this should work OK - but it doesn't.
-
I seem to have identified part of the issue and that is my 'tarpit' on the mail server, I had this set to 20 seconds so Postfix needs to be patient or I could do with knowing where to set how long it waits for the server to respond. For now I've reduced it to zero on the server and it seems to be working..
While playing with this to identify the issue I just identified another behaviour, but this one is totally 'unacceptable' - if the internal mail server REJECTS a message the Postfix duly responds to the sender with a reject message
The error that the other server returned was:
550 5.1.1 user@domain.co.uk: Recipient address rejected: undeliverable address: host 192.168.1.253[192.168.1.253] said: 553 5.1.8 Sender address <double-bounce@_._.*>domain does not exist (in reply to MAIL FROM command)The problem here is the message returned contains the internal IP address and NOT the public address - this needs to be changed - when sending messages like this the internal IP detail must not be revealed - the public IP must be substituted. This could also do with a mechanism to modify the 'Sender' e-mail address from double-bounce@_._.* in the gui to whatever we want.
Note - I changed the double-bounce address using custom command double_bounce_sender to be from an invalid domain to produce this message, I've since changed it back to one that works OK - NOTE - if a message is REJECTED by the mail server regardless of the reason you must NOT reveal the internal IP details in the message - is this an easy fix?
AND - there's more …
I have noticed that if I send a mail with multiple address's on the 'To' line that when it is pushed into my mailbox that each address is replaced with a copy of the destination i.e if I send to
user1@domain1.com, user1@domain2.com
when it appears in user1@domain1.com's inbox the 'To' line shows
user1@domain1.com, user1@domain1.com
and when it appears in user1@domain2.com's inbox the 'To' line shows
user1@domain2.com, user1@domain2.com
Another element that needs to be thought about is the response mechanism. If a user doesn't exist I want the system to 'swallow' the request and not to respond - by responding you leave the system open to harvesting attacks where a spammer sends lots of mails to 'random' account names within a domain and then vets the responses anything that doesn't generate a 'no such user' message being a positive, very soon after spam starts arriving, I proved this by setting up an account 'support' that they always seem to try but used it nowhere - and it soon started getting spam.
How can responses be 'tailored' or adjusted such that this kind of address harvesting doesn't work. You obviously can't hide a domain, you still need to work properly with SMTP senders so there must be a way to 'not respond' in a way that assists spammers - or to 'lie' - what about sending a 'no such domain' response for non existent users, this will fail permanently or sending a 'cannot deliver now try later' - the latter will choke their servers to death on retries. I can handle the rest by using 'non standard names for things such as sails instead of sales - or something even more cryptic.
What about configuring a block on any site / IP making more than X connection attempts to port 25 within X seconds.</double-bounce@_._.*>/user@domain.co.uk
-
While playing with this to identify the issue I just identified another behaviour, but this one is totally 'unacceptable' - if the internal mail server REJECTS a message the Postfix duly responds to the sender with a reject message
The error that the other server returned was:
550 5.1.1 user@domain.co.uk: Recipient address rejected: undeliverable address: host 192.168.1.253[192.168.1.253] said: 553 5.1.8 Sender address <double-bounce@_._.*>domain does not exist (in reply to MAIL FROM command)The problem here is the message returned contains the internal IP address and NOT the public address - this needs to be changed - when sending messages like this the internal IP detail must not be revealed - the public IP must be substituted. This could also do with a mechanism to modify the 'Sender' e-mail address from double-bounce@_._.* in the gui to whatever we want.
Note - I changed the double-bounce address using custom command double_bounce_sender to be from an invalid domain to produce this message, I've since changed it back to one that works OK - NOTE - if a message is REJECTED by the mail server regardless of the reason you must NOT reveal the internal IP details in the message - is this an easy fix?</double-bounce@_._.*>/user@domain.co.uk
You should be able to put something like this in your custom main.cf but I haven't tried it myself. It should replace the "host … said: ..." and not divulge the internal IP.
unverified_recipient_reject_reason = Recipient refused deliveryI have noticed that if I send a mail with multiple address's on the 'To' line that when it is pushed into my mailbox that each address is replaced with a copy of the destination i.e if I send to
user1@domain1.com, user1@domain2.com
when it appears in user1@domain1.com's inbox the 'To' line shows
user1@domain1.com, user1@domain1.com
and when it appears in user1@domain2.com's inbox the 'To' line shows
user1@domain2.com, user1@domain2.com
Sorry, no suggestion for that one.
-
I tested this:
unverified_recipient_reject_reason = Recipient refused deliverySadly, it didn't work.
The postfix documentation says, in relation to this parameter, "Do not specify the SMTP status code or enhanced status code."
No way in the package to override the default unverified_recipient_reject_code = 550
-
I tested this:
unverified_recipient_reject_reason = Recipient refused deliverySadly, it didn't work.
The postfix documentation says, in relation to this parameter, "Do not specify the SMTP status code or enhanced status code."
No way in the package to override the default unverified_recipient_reject_code = 550
I think you need to specify the unverified_recipient_reject_reason = Recipient refused delivery first in the config to make it work as the order of the rules will affect the response.
To do this try editing /usr/local/pkg/postfix.inc
line 543 "smtpd_recipient_restrictions = permit_mynetworks,"
put the reject BEFORE the "permit_mynetworks"
I don't think putting it in the custom config will work as the rules are not ordered in the correct sequence.
Note if you reinstall you will loose this setting.
-
Tried it, didn't work.
Surely this behaviour must have been spotted before, am I the only one that finds the revealing of internal IP address's unacceptable. This should be set to the 'domain' and public IP.
-
Some more research turned up this:
Hello,
I currently use relay_domains and relay_transport as a means to relay
email on to another mail server which hands off to the MDA. Everything
works well. Occasionally there may be a delivery problem when talking
to the relay_transport that results in a bounce being generated by
postfix - an expected behavior of any MTA. What I need to do is hide
details (the IP address) of the relay_transport in the bounce message
due to security concerns. I tried using the bounce template
configuration to do this, but postfix adds this information anyways. Is
there any way to hide this information?
… [show rest of quote]Is this about the RECEIVED headers in the undeliverable message? If so
then you need a content filter or header_checks rule.Is this about the remote hostname[address]:port in the server response?
If so then you need Postfix 2.12 with smtp_delivery_status_filter to
sanitise the delivery status message.Wietse
Current package is based on 2.10
-
I shall explore and report, I did find smtpd_reject_footer but this appears one line below the 'offending' one and doesn't help to 'correct' the IP returned in the message.
-
The error that the other server returned was:
550 5.1.1 user@domain.co.uk: Recipient address rejected: undeliverable address: host 192.168.1.253[192.168.1.253] said: 553 5.1.8 Sender address <double-bounce@_._.>domain does not exist (in reply to MAIL FROM command)</double-bounce@..>/user@domain.co.ukSorry but I can't reproduce this, your internal server (192.168.1.253) should never give such error (Recipient address rejected) since only valid email recipients/domains should pass postfix.
Another element that needs to be thought about is the response mechanism. If a user doesn't exist I want the system to 'swallow' the request and not to respond - by responding you leave the system open to harvesting attacks where a spammer sends lots of mails to 'random' account names within a domain and then vets the responses anything that doesn't generate a 'no such user' message being a positive, very soon after spam starts arriving, I proved this by setting up an account 'support' that they always seem to try but used it nowhere - and it soon started getting spam.
How can responses be 'tailored' or adjusted such that this kind of address harvesting doesn't work. You obviously can't hide a domain, you still need to work properly with SMTP senders so there must be a way to 'not respond' in a way that assists spammers - or to 'lie' - what about sending a 'no such domain' response for non existent users, this will fail permanently or sending a 'cannot deliver now try later' - the latter will choke their servers to death on retries. I can handle the rest by using 'non standard names for things such as sails instead of sales - or something even more cryptic.
I'm sure this would break some RFCs, 'swallow', 'not respond' or 'lie' would all be the same as 'no such user', there is just valid or not, no mater how you name it. And 'support@domain.com' is a very common account but eg. 'ranga.yogeshwar@domain.com' is not and guessing/harnessing such real mail accounts would be highly infective and take zillion of years.
What about configuring a block on any site / IP making more than X connection attempts to port 25 within X seconds.
This can be easily abused and make your mail server DoS, think about it.
What's your internal MTA? I still believe you have some kind of misconfiguration here, try to keep your setup "simple" and make it work first and secure it second. Try to telnet or use SMTP diag, for me it looks like postfix and your internal server is accepting mails at the same time, thats why your internal server is responding that error, when postfix should do.
If you like to hide your internal MTAs IP from Headers just use IGNORE:
Remove Sensitive Information from Headers
/^Received: from MyMTA.local*/ IGNORE
/^Received:.*with ESMTPS/ IGNORE
/^X-Originating-IP:/ IGNORE
/^User-Agent:/ IGNOREBut I think this is not really related to your problem…
-
My problem here is that
a) Postfix is reporting the error but not correctly embedding the public IP in 'error' responses to the sender.
b) I know that what I want breaks a few rules but if a user account doesn't exist I want it to behave like spamd and tie up the senders 'server' by grey listing - I don't want to send a "doesn't exist" reject response.
c) I don't want a system that allows infinite login attempts with a different username from the same IP in a short time frame - brute force attack basically. I am aware of the DOS issue but there needs to be a solution to prevent this 'hammering' in an 'elegant' manner.
-
Tried it, didn't work.
Surely this behaviour must have been spotted before, am I the only one that finds the revealing of internal IP address's unacceptable. This should be set to the 'domain' and public IP.
What does postix say is happening in the log when you see this behavior?
/var/log/maillog
Also I am not sure as to why you have your internal email server rejecting the message from postfix. Maybe I am not just understanding you correctly. Postfix should be rejecting the message not you email server.
Postfix should be checking for valid receipents and rejecting them. You should see this in the log "550 5.1.1 <@.com>: Recipient address rejected: User unknown in relay recipient table.
You need to have a comand line in the access lists -> "filters while receiving mail"
It should be something like this "/^from:/ HOLD"
Otherwise postfix is not going to do anything.
-
Config is as per previous posts. Listening on localhost which is NAT'd from the public IP, two domains each mapped to its own unique internal IP. The detail appearing in the system status log is merely a cut down version of the one sent to the e-mail sender - but it contains the domains private local IP's and not the public one.
There's nothing wrong with my MTA's internal or external - this behaviour is coming from my mail server - but Postfix is simply repeating the message and it shouldn't - I need to find an expression to force the local IP to be replaced with the public IP - but ONLY where appropriate.
I DO NOT want reject responses for non existent user accounts - at least on the first attempt within a set period since most 'spammers' don't behave or retry in line with RFC guidelines. I want REJECT converted to TRY AGAIN LATER .. something that SpamD can do but using SpamD with postfix has proved less than successful.
I'm stunned how hard this seems to be for Postfix - at least without hacking around in the code - I've tried numerous Postfix settings now and all have failed - presumably because of the order encountered - or I'm just not entering them as it expects - lets face it script lines full of 'regex' expressions aren't exactly easy to read, assuming that I'm even looking in the correct .inc files.
My mailserver is an enterprise class mailserver (Kerio) and even it seems unable to handle the simple concept of 'black hole' mailboxes and rejects instantly any mail for non existent accounts, it is very verbose in its response too. It won't block multiple failed login attempts from the same IP and will happily converse with a brute force script all day long - I have better things to waste CPU cycles and bandwidth on.
I am tentatively planning a move to hMailServer because it will block bad behaviour from IP address's, but not until it gets TLS sorted out, maintaining Kerio is just too expensive for our needs but I'm not prepared to go 'open text'.
With regards the mail log there is no such file in the var/log folder. I report messages to the system log and a syslog server.
-
I am not sure what the log looks like when reporting to the system log. As for the syslog server I don't this this is even an option in postifx.
If you go to the configuration page/general/logging/destination select the second item var/log/maillog. Then restart postfix I think you will get a better ideal of what is going on in postfix.
also in the log level set it at least to 2.
post the portion of the log as I would be interested to see it.
-
syslog isn't an option in postfix and is why I send messages to the system log - because that can be sent to a syslog server. I'll try the log thing and see if the information's any different, my debug level is currently 2.
-
There's nothing wrong with my MTA's internal or external - this behaviour is coming from my mail server - but Postfix is simply repeating the message and it shouldn't - I need to find an expression to force the local IP to be replaced with the public IP - but ONLY where appropriate.
We all said it more as once you need to stop forwarding mail addresses from postfix which are non-existing to your internal server, thats postfix job.
My mailserver is an enterprise class mailserver (Kerio) and even it seems unable to handle the simple concept of 'black hole' mailboxes and rejects instantly any mail for non existent accounts, it is very verbose in its response too. It won't block multiple failed login attempts from the same IP and will happily converse with a brute force script all day long - I have better things to waste CPU cycles and bandwidth on.
I am tentatively planning a move to hMailServer because it will block bad behaviour from IP address's, but not until it gets TLS sorted out, maintaining Kerio is just too expensive for our needs but I'm not prepared to go 'open text'.
BenKenobe, if I understand your intention right, you won't be happy with postfix. Postfix/Mailscanner should be the one and only layer of defence, since bad mails should be disarmed BEFORE the reach the internal server, but in your scenario your internal server looks like a second layer of defence, which will not work well in conjunction with Postfix/Mailscanner.
-
I'm quite happy to drop the 'secondary' defenses once I'm satisfied that the primary are working well.
How do I stop Postfix forwarding or rejecting non existent address's though, and how do I make it substitute the local mail server IP for the 'correct' public one.
I have explicitly stated which accounts are acceptable on the 'Custom Valid Recipients' tab, by doing so would expect Postfix to deal with all others but it still checks against the mail server for 'account existence' and uses the message returned by the mail server so even though it doesn't pass the mail it still checks for the accounts presence every single time - which I don't think it should do, it should only attempt delivery of specifically identified accounts - all others need to be handled 100% by Postfix with no involvement of the mail server at all.
I have removed all the tarpitting and spam traps on the Kerio, but I have put SpamD back in front of Postfix - this has had the same effect it had before though - it can take hours for valid mails to hit the inbox because many vendors send from continually changing IP address's, I really don't like it much but it does some of what I need.
Incidentally I have had maillog enabled for 18 hours now and it is still empty !! - not something I expected at all because I'm still getting E-Mail.
Starting to wonder if I have a duff install.
-
BenKenobe,
You could limit the number of connections from an IP in a given timeframe on the firewall rule you have for SMTP. Under Advanced features.
I'm not arguing with what you're looking for but I don't think exposing an RFC 1918 address to the sending mailserver in those reject messages is really that worrying. To exploit that knowledge would require compromise of your firewall or an internal host. Then you would have much more to worry about.
I can't see how you get that reject on invalid domain message. postfix should reject mail for any domain that it's not configured to relay for, without reference to your mailserver.
The double-bounce is used by postfix to check the validity of a recipient in a domain that it is configured to relay. However, I think it does cache recent ones to avoid that extra effort.
