Postfix mailrelay

marcelloc

While using postscreen, the first communication for each ip will always be 'rejected'. After this all communication will be fine.

You can reduce the Waiting time on antispam tab.

I do not recomend disabling postscreen.

In package version 2.2 there is a search tool, So you can see Message delays, status, etc…

Guest

@marcelloc:

While using postscreen, the first communication for each ip will always be 'rejected'. After this all communication will be fine.

And this is "hard coded", and i have to stop using postfix altogether if this function is somewhat unwanted? Lets say you are waiting for a mail "then and there", and you might end up waiting 4-5 hours (depending on the sending smtp server settings), this function is not "always wanted" from my pov.

A good example as i said before would be a "password reset" mail. Lets say you are logging onto a site you dont remember the password for, do a password reset, and the link for that is ofc sent by mail. This is being rejected 1st round. The sending server could have 2 hours until it sends the mail again (Talking corporate size of eg. sony.com, og blizzard.com and such). They might not have 5 minute resend on their possibly huge mailqueue. And a "Server unavailable" status might also possibly be put in the "dont rush" line aswell. What do i do? Try again the password reset and get the next mail through ofc (since its now approved), only to read "Sorry, you cannot reset your password until 24 hours". Thank you :P (did i mention this was not a hypothetical example?)

Yes, its a small matter, but for a day to day use for ME personally, its bothersome. To be quite honest, i cant on the top of my head come up with a positive reason why this function cannot be turned off somehow :) I can come up with other examples aswell if you like? Lets take gmail, the other day it took a little over 1 full hour until it sent the mail through, even after i had resent the initial mail. This was my own account, so i could just resend the mail 5 times in a row, but it IS a bit awkward at times (even tho it was easy to delete the 2nd copy of the mail after it came through)

C

Guest

This is what happened when i sent a mail from gmail to myself:


Nov 15 21:00:48 	postfix/qmgr[56996]: 413A3192DC88: removed
Nov 15 21:00:48 	postfix/smtp[31699]: 413A3192DC88: to=<me@mydomain.net>, relay=192.168.0.xx[192.168.0.xx]:25, delay=0.33, delays=0.29/0.01/0.01/0.02, dsn=2.0.0, status=sent (250 2.0.0 4ec2c4ef-00000019 Message accepted for delivery)
Nov 15 21:00:48 	postfix/qmgr[56996]: 413A3192DC88: from=<me@gmail.com>, size=1679, nrcpt=1 (queue active)
Nov 15 21:00:48 	postfix/cleanup[31669]: 413A3192DC88: message-id= <cahssl6zcgpyt0rke_nkbz=cvme06r01df09wsff4ss6qaee=+g@mail.gmail.com>Nov 15 21:00:48 	postfix/smtpd[31372]: 413A3192DC88: client=mail-fx0-f51.google.com[209.85.161.51]
Nov 15 21:00:47 	postfix/smtpd[31372]: connect from mail-fx0-f51.google.com[209.85.161.51]
Nov 15 21:00:47 	postfix/postscreen[31063]: PASS OLD [209.85.161.51]:43423
Nov 15 21:00:47 	postfix/postscreen[31063]: CONNECT from [209.85.161.51]:43423

----

Nov 15 20:54:44 	postfix/postscreen[56655]: DISCONNECT [209.85.161.51]:49020
Nov 15 20:54:44 	postfix/postscreen[56655]: PASS NEW [209.85.161.51]:49020
Nov 15 20:54:44 	postfix/postscreen[56655]: NOQUEUE: reject: RCPT from [209.85.161.51]:49020: 450 4.3.2 Service currently unavailable; from=<me@gmail.com>, to=<me@mydomain.net>, proto=ESMTP, helo= <mail-fx0-f51.google.com>Nov 15 20:54:33 	postfix/postscreen[56655]: CONNECT from [209.85.161.51]:49020</mail-fx0-f51.google.com></me@mydomain.net></me@gmail.com></cahssl6zcgpyt0rke_nkbz=cvme06r01df09wsff4ss6qaee=+g@mail.gmail.com></me@gmail.com></me@mydomain.net>

That was 6 minutes.

Yes, its not long, for THAT particular instance, but this time around i was "lucky" on queues i guess.

Is there a "non gui" option i can put into some config file to disable this default "always reject first try" function?

C

PS. Yeah, i guess im a nag :P Awesome work on the addon tho.. i just updated to the newest version btw.

Guest

Hmm.. could it be the Postfix "zombie blocker" feature?

C

podilarius

From my POV it is desired. If a remote mail server cannot resend after 69 seconds, then it is probably spam to begin with. Then again, I use postgrey on my mail servers for that feature and not my firewall. I have not had a problem with gmail going though. The longest I have had to wait on an email was 5 minutes.

marcelloc

@Cybdex:

Im currently using the postfix package to weed out the most of the spam and bogus relay attempts.

Great news, you could congratulate postscreen for that.
.
.
.
@Cybdex:

Hmm.. could it be the Postfix "zombie blocker" feature?

I told you in all posts that it is a postscreen feature.
take a look on postfix documentation to see how it works.
http://www.postfix.org/POSTSCREEN_README.html

And if you look in antispam tab of postfix package you can see a way to disable this feature.

Take postscreen some hours. Every time you stop and restart postscreen, the whitelist is cleaned.

podilarius

@marcelloc:

Take postscreen some hours. Every time you stop and restart postscreen, the whitelist is cleaned.

That is not always a good thing. This should probably be persistent across service restarts and reboots with a manual or scheduled cleaning of the while list. Even better if you could clean out entries that are older than a certain age.

marcelloc

It's done by postscreen, not by me.

Before version 2.1 of this package, every apply postfix was killed and restarted.
I've changed it to just a reload if services are up.

Take a look on postscreen readme

http://www.postfix.org/POSTSCREEN_README.html

podilarius

If this is set:

postscreen_cache_map (btree:$data_direc-tory/postscreen_cache)
Persistent storage for the postscreen(8) server
decisions.

Will it not persist the temporary white list across server and service restarts?

marcelloc

The location of this file in pfsense is /var/db/postfix/postscreen_cache.db

Postscreen readme says that it's a temporary white list, not persistent.

Temporary whitelist test

The postscreen(8) daemon maintains a temporary whitelist for SMTP client IP addresses that have passed all the tests described below. The postscreen_cache_map parameter specifies the location of the temporary whitelist. The temporary whitelist is not used for SMTP client addresses that appear on the permanent access list.

Guest

@podilarius:

@marcelloc:

Take postscreen some hours. Every time you stop and restart postscreen, the whitelist is cleaned.

That is not always a good thing. This should probably be persistent across service restarts and reboots with a manual or scheduled cleaning of the while list. Even better if you could clean out entries that are older than a certain age.

That is probably what stumbled me aswell, as during my testing of this "feature" the postfix service was restarted frequently (when changing options/blacklist and whatnot). If it would be a "approved list" saved for future referance, and possibly as you say a "age scrubbing" setting for this it would make things a lot smoother. (Or even a editable list)

However, disabling the "zombie blocker" seems to have fixed my gripe. It was not THAT clear for a "non guru" to sift through the documentation and realize that this feature was the culprit that caused "the default behaviour to reject every first connection".

If some day a feature that Podilarius describes here comes configurable and available, i would be happy to give it a new go :)

Thanks for your help guys :)

C

marcelloc

The postfix package helps email admins to configure it.

All options where included after many hours reading postfix documentation but you need to know about smtp to understand what they mean.

If you go to ACLS/Filter Maps, you can whitelist some networks/domains in Client Access List.

All features discussed in this forum topic are available in this package.

podilarius

@marcelloc:

The location of this file in pfsense is /var/db/postfix/postscreen_cache.db

Postscreen readme says that it's a temporary white list, not persistent.

I pulled what I posted from the README. So, the temporary white like might be persistent if set and will be cleared if not set? Documentation seems to not be clear on that. It might be temporary as in the age thing will remove entries. I cannot test this ATM … but should be something the maintainers of postscreen could clear up.