Postfix - antispam and relay package

Bismarck

FlashPan you definitely need to fine tune your rbl list:

Received: from fieldandstream.ie ([::ffff:109.229.186.118])

Summary information for 109.229.186.118/32
Note: Times shown are for the latest entry only!
Found 2 network entries and 0 host/domain entries.

Problem Entries, (listings will cause email problems.)
1 "Hacked" entries [04:29:20 13 Sep 2011 GMT+00].
6 "Spam" entries [17:17:17 30 Aug 2014 GMT+00].

http://www.anti-abuse.org/multi-rbl-check-results/?host=109.229.186.118

And how often do you update your spamassassin rule subscriptions?

FlashPan

Sigh ??? this is what I am not understanding ;)

My options under Antispam > RBL Server List all seem correct.

zen.spamhaus.org*2, bl.spamcop.net, dnsbl.sorbs.net

As for spamassassin, you just gave me an answer in antoehr threas but think I may have borked the package as now it will not star for some reason.

Getting very close to pulling hair out time :)

Thanks Bismark you are going above and beyond here.

Bismarck

Try this:

recent.spam.dnsbl.sorbs.net2, zen.spamhaus.org, bl.spamcop.net, dnsbl.sorbs.net, b.barracudacentral.org, dnsbl-1.uceprotect.net, ix.dnsbl.manitu.net, bl.spameatingmonkey.net, list.dnswl.org-5

And set RBL threshold 2.

This should keep the most nasty stuff away, you can add how many you like/fit your needs…

Watch it with

tail -f /var/log/maillog

BTW don't use google DNS as your system DNS, use those from your ISP.

http://blog.clairelogic.net/?p=67

cheers!

FlashPan

Thanks for that,

Yep I had my 3 rbls and threshold set to 2.

Have updated to the rbls you've given but still no joy now. Before MailScanner died on me emails were blocked from http://www.crynwr.com/spam. Now MailScanner has gone these emails are getting through.

Sadly from Saturday I am away for the next 2 weeks. I think I need to step back from this and completely remove postfix and mailscanner and re-install them from scratch (if only for my own sanity :P)

I'm very sorry about this especially to you Bismarck as you have tried very hard to help me and I really do appreciate all your input and help.

Before I depart though I know that simply uninstalling both packages will not remove the config settings I've made. I've been scouting around but from where would I find these configs to delete directly? As I said want to start with a clean sheet.

So if I get the 2 packages removed expect me back here in about 2.5 weeks crying again :)

Cheers all

FlashPan

Well this will be my last reply before I disappear for the next couple of weeks.

My postfix is now working and the rbls are blocking as they should. Removed postfix, removed anything left behind after uninstall and re-installed. (My original config was still intact though - would still be nice to find out where that is stored?)

I also discovered a misprint for an acl section

Access Lists > MIME:

The example says to use /^name=[^>](com …........etc to block certain file extensions. For me this does not work. I've used /name=[^>](com …........etc remove the ^ and loose the text after /REJECT

I've tested this by emailing myself a test file with a safe extension like .bit Added .bit into the string and that email does not get to me and a bounce back is received to the sender.

"Server refused mail at END OF DATA - 550 5.7.1 message content rejected"

If I didn't make the changes above the email and attachment would still come through.

Hope this helps someone :)

My Mailscanner is still shot, something to do with perl and EN language settings I think??? But that's for the other thread and when I get back.

Cheers

ApolloDS

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 = 1

You 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

BenKenobe

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>

Bismarck

@BenKenobe:

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.

BenKenobe

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.

BenKenobe

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

biggsy

@BenKenobe:

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 delivery

@BenKenobe:

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

Sorry, no suggestion for that one.

biggsy

I tested this:

unverified_recipient_reject_reason = Recipient refused delivery

Sadly, 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

mschiek01

@biggsy:

I tested this:
unverified_recipient_reject_reason = Recipient refused delivery
Sadly, 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.

BenKenobe

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.

biggsy

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

BenKenobe

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.

Bismarck

@BenKenobe:

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.uk

Sorry 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:/ IGNORE

But I think this is not really related to your problem…

BenKenobe

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.

mschiek01

@BenKenobe:

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.

BenKenobe

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.