On Sun, May 1, 2016, at 09:34 AM, Alice Wonder wrote:
> I reduced the blacklists I use because every now and then I find my own
> servers on them when I know for a fact there was no unsolicited mail
> from them.
I'm in the same boat -- but typically want to know IF I'm on a list, especially
i
> If you must spread incorrect information, you can do that elsewhere.
Asking a question that doesn't meet your ... um ... standards ... is somehow
'spreading incorrect information'?
> I don't want incorrect information on this mailing list.
And I don't want lip & attitude from grumpy old far
Hi Alice,
On Sun, May 1, 2016, at 08:44 AM, Alice Wonder wrote:
> If the IP is on a blacklist I use, I just let the blacklist deal with it via
> reject.
Generally, I do too. TBH, it's those new-not-yet-on-a-list IPs that got my
attention on this.
> I'm somewhat conservative with the blacklis
On Sun, May 1, 2016, at 08:07 AM, Wietse Venema wrote:
> > > > using REJECT does NOT accept the whole message, and sends a bounce
> > >
> > > No, it doesn't. Please see RFC 5321 for how SMTP works.
> >
> > Not the point of my question at all, but right, I used the improper term.
>
> You start
On Sun, May 1, 2016, at 07:27 AM, Wietse Venema wrote:
> jaso...@mail-central.com:
> > using REJECT does NOT accept the whole message, and sends a bounce
>
> No, it doesn't. Please see RFC 5321 for how SMTP works.
>
> Wietse
Not the point of my question at all, but right, I used the imp
I'm clear this has been asked a gazillion times; feels like I've now read half
the posts.
For incoming mail that matches with high-confidence a known bot/mass-mailer
restriction, is it 'best' to
DISCARD or REJECT?
I still can't convince myself of a clear answer, but am leaning to DISCARD.
M
On Wed, Apr 20, 2016, at 05:13 PM, Wietse Venema wrote:
> 3) qmgr selects a delivery agent.
>
> 4) The delivery agent does a partial delivery attempt and reports
>results to the verify daemon.
IIUC, looking at that^ and
http://www.postfix.org/OVERVIEW.html#delivering
in my case, that^ del
On Wed, Apr 20, 2016, at 05:13 PM, Wietse Venema wrote:
> This is what happens in the simple case.
>
> 1) smtpd talks to the cleanup server.
>
> 2) cleanup writes a probe message to the queue.
>
> 3) qmgr selects a delivery agent.
>
> 4) The delivery agent does a partial delivery attempt and
I invoke the address verification at the postscreen handoff smtpd.
>From the log you can see
connect from outside
Apr 20 15:28:35 mail01 postfix/postscreen[10625]: CONNECT from
[66.111.4.25]:42434 to [192.0.2.16]:25
dnsbl checks & pass
Apr 20 15:28:35 mail01 postfix/dnsblog[1
On Wed, Apr 20, 2016, at 12:34 PM, Wietse Venema wrote:
> As Noel says, keep it simple. Only when it works, add complexity.
Which is exactly what I'm trying to do.
I've got a completely working frontend/backend setup. No errors in logs.
When I add *one* thing, the address_verification step, it
On Wed, Apr 20, 2016, at 11:08 AM, Wietse Venema wrote:
> SENDMAIL(1) SENDMAIL(1)
>
> ...
>-bvDo not collect or deliver a message. Instead, send an email
> report after verifying each recipient address.
On Wed, Apr 20, 2016, at 10:25 AM, Wietse Venema wrote:
> jaso...@mail-central.com:
> > Do address_verification probes work when checking aliased or
> > plus-addressed addresses?
> >
> Verify probes work in the same way as real email, except that they
> are not delivered (with SMTP, Postfix aborts
Do address_verification probes work when checking aliased or plus-addressed
addresses?
E.g.,
I have a REAL address defined,
m...@example.com
address_verification probes work, and the mail's passed.
Atm, however, mail to both
me.al...@example.com (aliased to m...@example.com)
and
me+p
> Now to wait for something to trigger one of those double-bounce messages.
Ugh. Still undeliverable.
Well, I actually GET the email. Something 'internal' seems to be undeliverable.
Now 'mail for example.com loops back to myself' (not sure what I've done to
myself NOW. Grumble.)
Apr
Sry, talking to myself a bunch :-/
I changed
main.cf
- address_verify_transport_maps =
static:vpn:[back.mail01.example.com]:25
+ address_verify_transport_maps =
master.cf
[mail01.example.com]:25 inet n - n - 1 postscreen
I keep staring at this
Apr 19 14:48:31 mail01 postfix/vpn/smtp[21044]: connect to
back.mail01.example.com[10.1.1.16]:25: Connection refused
Apr 19 14:48:31 mail01 postfix/vpn/smtp[21044]: 3qqJYC3wYbz31Vm:
to=, relay=none, delay=0.1, delays=0/0.01/0.09/0,
dsn=4.4.1, status=undel
> The "connection refused" is the part that needs to be fixed.
VPN (temporarily?) down? firewall issue? "wrong" destination?
something else?
Starting with those^ to narrow down, looking backwards through my logs - for
cases of 'double-bounce' & 'connection refused' - this apparently has been
go
I'm working on a relay to a backend postfix instance across a VPN link.
My 'flow' is
postscreen
postscreen-smtp
preQ milters
postQ spam filter
relay over VPN to the backend
At the moment, mail's getting both received OK from the net, and sent to it,
over
On Tue, Apr 19, 2016, at 10:20 AM, Bill Cole wrote:
> > I'm using an lmdb list.
>
> I doubt that it is actually working as you expect...
And a big 'oops!' here. All my _other_ lmdb tables are fine. Of course, the
one example I'm asking about I got sloppy and 'polluted' with regex.
Thanks for
I'm doing helo_access checks to rid myself of some list-cleaning pests. This,
plus ns_access checks works well.
I'm using an lmdb list.
IIUC the way the matches work (?), both of these should do the same thing
cat helo_access
/.*managablelight.*/ REJECT
On Tue, Apr 19, 2016, at 07:56 AM, Noel Jones wrote:
> Nothing unusual here...
On Tue, Apr 19, 2016, at 08:01 AM, Bill Cole wrote:
> It's pretty much "business as normal"
Great, that's what I'm looking for -- some confidence that there's NOT a prob
in my config.
That string of "/000" was jus
On Tue, Apr 19, 2016, at 06:55 AM, Wietse Venema wrote:
> jaso...@mail-central.com:
> > I've got after-220 tests turned off
>
> As documented, postscreen will redirect a bad client to its internal
> SMTP engine, in order to log the client, helo, sender and recipient
> for forensic purposes (why
> I'm wondering what to do in case of future attacks like this.
I'm using a fail2ban+ipsets to catch these quickly & ban them efficiently.
Works well. Simply use a regex like in those grep commands to match.
Make sure you test your matches -- using a combo or online regex tester &
fail2ban-re
I've got after-220 tests turned off
postconf | grep postscreen | egrep -i "bare|non_smtp|pipelining"
postscreen_bare_newline_action = ignore
postscreen_bare_newline_enable = no
postscreen_bare_newline_ttl = 30d
postscreen_non_
On Sun, Apr 10, 2016, at 07:46 PM, Bill Cole wrote:
> On a system where you know enough about all your users to know that they
> don't want to get critical email from clueless sources, you can make
> restrictive choices with no trouble. If you don't actually know that,
> choosing to require se
On Sun, Apr 10, 2016, at 03:13 PM, Bill Cole wrote:
> On 9 Apr 2016, at 12:45, jaso...@mail-central.com wrote:
>
> > I block on strict FAILs of any if SPF, DKIM or DMARC. *missing*
> > support for those is logged, but not - yet - acted on.
>
> as is raising the bar too high on ciphersuites.
T
On Sun, Apr 10, 2016, at 06:42 AM, Wietse Venema wrote:
> > > No-one can connect to this from outside.
> >
> > That's correct. Not currently, to this current machine/port, in
> > this configuration.
>
> If someone can connect from outside to your 127.0.0.1 port, then
> you have a serious infra
On Sat, Apr 9, 2016, at 05:40 PM, Wietse Venema wrote:
> Who cares?
Obviously you don't.
But I do. That's why I'm asking. That's good enough for me.
> No-one can connect to this from outside.
That's correct. Not currently, to this current machine/port, in this
configuration.
> But, if you
On Sat, Apr 9, 2016, at 02:25 PM, jaso...@mail-central.com wrote:
> I think that's "in postfix". Looking around to see.
is the issue of changing
... MTA(smtp:[127.0.0.1]:13002) ...
to something descriptive that I specify
... MTA(my_internal_server_A) ...
a matter of http://www.postfix.org/A
On Wed, Apr 6, 2016, at 11:49 AM, jaso...@mail-central.com wrote:
> If it's seeing the 550, how can I stop exposing/reporting back "from
> MTA(smtp:[127.0.0.1]:13002):" ? If it's just internal to my setup, then I
> don't care.
It's definitely being reported back to the sender.
: host
On Sat, Apr 9, 2016, at 02:02 PM, Viktor Dukhovni wrote:
> Your server, your rules, but be prepared to refuse a lot of legitimate
> email.
True, but that's neither my point, nor my goal.
And, THESE (sadly, neither of which I've seen)
> https://www.google.com/transparencyreport/saferemail/
On Sat, Apr 9, 2016, at 01:16 PM, Viktor Dukhovni wrote:
> Is it bad that you can board a bus without having a passport?
Since you're going to torture me with a metaphor ;-) I'll answer :
It depends.
But I DO know that dutifully skimming the scum off the top of a pot of boiling
stock DEFINITEL
On Sat, Apr 9, 2016, at 12:27 PM, Viktor Dukhovni wrote:
> The most recently removed ciphers are at the front of the list when
> ciphers are restored. Therefore, "aNULL:-aNULL:ALL:@STRENGTH" is
> different from "ALL:@STRENGTH" in that at any given strength the
> aNULL ciphers are listed first.
While looking through the Postfix default configs about TLS ciphers, I noticed
these
grep -i " anull" main.cf.default
tls_export_cipherlist =
aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH
tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH
On Sat, Apr 9, 2016, at 09:33 AM, li...@lazygranch.com wrote:
> Per the DROWN mitigation, I stopped allowing sslv2 and sslv3
Did that as well. Actually before even that point.
> so I made it a point to read the headers and look for encryption issues.
I admit I never even bothered to look for
I'm setting up mandatory TLS policy for a couple of private client servers,
using
- smtpd_tls_security_level = may
+ smtpd_tls_security_level = encrypt
I started wondering whether it wouldn't be a bad thing to require ALL email
delivered to my server, from anywhere, to use TLS.
Rea
With postscreen in place, bad bots arr getting fended off.
Many give up and go away after a couple of tries.
Some, these days mostly 'ymlf-pc' bots, are more persistent.
Eg, this one
Apr 8 04:17:20 mail01 postfix/postscreen[20412]: CONNECT from
[37.49.226.17]:52066 to [192.0.2.17]:25
On Fri, Apr 8, 2016, at 11:05 AM, /dev/rob0 wrote:
> /^User[^\.]*/i REJECT your message here
So it *is* true that that *starts* at the beginning of the line (and so the
"^U"). That makes it easier to not fubar it.
> A case-sensitive string that begins with "User" followed by zero or
> more
Wietse,
On Fri, Apr 8, 2016, at 10:04 AM, jaso...@mail-central.com wrote:
> > Writing to the postscreen access list (with fail2bain etc.) is
> > generally not supported. It can be done with LMDB but only if you
> > use the locking protocol described in lmdb_table(5). Otherwise the
> > result will
On Fri, Apr 8, 2016, at 09:58 AM, Wietse Venema wrote:
> It is a superset, as the postscreen_blacklist_action parameter alows
> you to choose between dropping the connection and logging the helo,
> mail from and rcpt to, so that you can find out what mail is blocked.
Good point. I've so far been
To date I've maintained & deployed a firewall blacklist of bad-actor, port25
CIDRs.
Its blocking is obviously in front of Postfix, and logs if/as I choose to my
firewall logs.
I populate it both manually, and append it using fail2ban.
Its a 'fast' IPSET hash table, not just iptables.
postscre
On Fri, Apr 8, 2016, at 08:22 AM, /dev/rob0 wrote:
...
> Rejected by your smtpd's reject_non_fqdn_helo_hostname restriction.
...
> Rejected by postscreen as a pre-banner talker.
...
> And that's the postscreen_dnsbl_threshold having been met. Also, a
> different non-FQDN EHLO string.
Yes, as I
I want to add a helo_access block entry for literal matches of "User". Because
"user" is uesd all over the place, I want to make sure I don't screw this up.
Here are three instances that I'd like to match,
Jan 17 19:21:13 mail01 postfix/psint/smtpd[24295]: NOQUEUE: reject:
EHLO from 75
On Tue, Apr 5, 2016, at 07:09 PM, Scott Kitterman wrote:
> I'm pretty sure it's a local configuration error. I'll address it in the
> upstream bug.
just fyi, it took a few steps, but it's solved & working.
See https://bugs.launchpad.net/pypolicyd-spf/+bug/1566561/comments/13
In summary I
r
I added SPF and header_checks to my Postfix setup.
I'm following the message path, and have a couple questions about what error
gets reported back to the sender.
After postscreen PASS, I check for SPF, then hand off to Amavis preque for DKIM
psint pass - - n - - smtpd
-o recei
On Wed, Apr 6, 2016, at 10:20 AM, Noel Jones wrote:
> A third-party policy daemon or milter is required for SPF. Postfix
> ships with support for these external third-party programs.
>
> Postfix does not include nor officially recommend any particular
> add-on SPF policy or milter.
If that's t
Since pypolicyd-spf has been causing me lots of problems (upstream is helping
on it at launchpad), I decided to look for a more reliable alternative just in
case.
The Postfix Add-Ons page (http://www.postfix.org/addon.html) says
Note: Postfix already ships with SPF support, in the form
On Wed, Apr 6, 2016, at 09:12 AM, Noel Jones wrote:
> > postfix/postscreen[18826]: cache
> > btree:/var/lib/postfix/postscreen_cache full cleanup: retained=224
> > dropped=12 entries
> >
> > It looks like it's happening because they're 'full' at the time.
> They are removed because they are
In my logs I see postscreen cache cleanups
postfix/postscreen[18826]: cache
btree:/var/lib/postfix/postscreen_cache full cleanup: retained=224 dropped=12
entries
It looks like it's happening because they're 'full' at the time.
Under "CACHE CONTROLS" & "RESOURCE CONTROLS" @
http://www.
I'm pretty sure this is a pypolicyd issue, not Postfix, but asking here just in
case someone's seen it already.
I've moved my Postfix SPF checks out of Amavisd/Spamassassin to pypolicyd-spf.
It works as expected, when I use "Header_Type=SPF" in the config. When I
switch ONLY the "Header_Type=A
> I'll set the
>
> smtpd_delay_reject=yes
>
> and watch that for awhile to see what happens.
Okay, I remembered what I was *trying* to make sure happened by setting
smtpd_delay_reject=no
For now I'm trying to do everything stepwise and more-or-less separated in
Postfix config,
I build & use the latest Postfix release from source instead of depending on
distro packages.
I use regex alot, including in Postfix. I try to keep up to date with upstream
PCRE too.
PCRE has released a v2, where all new features appear, and maintains (bug-fixes
only) v1.
http://www.
Yep, I had
smtpd_delay_reject=no
set in main.cf
Wondeing WHY I
"set the non-default non-recommended "smtpd_delay_reject = no"."
looking at my notes, I found
...
With smtpd_delay_reject=no milters always follow built-in restriction
processing.
With smt
On 04/05/2016 07:08 AM, Wietse Venema wrote:>> I'm not exactly sure why I'm
getting one CONNECT and 2 REJECTs.
>
> The client sent two RCPT TO commands. Why did it try the same
> recipient twice? No idea, I didn't write the client code.
I was just looking to make sure I'm not doing something wro
I've added blocking by TLD to my setup. Right now, it blocks at helo checks.
It's working.
Looking at my logs, EVERY time I get a 'bad TLD' connection, there's always 2
similar reject entries, but only one CONNECT/PASS For example
Apr 4 19:55:38 mail01 postfix/postscreen[7444]: CONNE
In my
smtpd_helo_restrictions
I've had a
check_helo_access lmdb:/path/table
I want to add a 2nd table to check.
Is the correct usage for multiple tables for the same check type to use 2
separate instances, e.g.
check_helo_access lmdb:/path/table1
check_helo_access pcre:/path/table2.
On Fri, Apr 1, 2016, at 12:21 PM, Noel Jones wrote:
> dwl.spamhaus.org lists domain names and is not compatible with
> postscreen, which only knows the IP.
I needed to be reminded of that :-/
> dwl can be used in one of the
> smtpd_*_restrictions sections.
> http://www.postfix.org/postconf.5.h
> > Running Postscreen after a spam appliance is pointless. It is a
> > spambot detector (in more sophisticated words, it implements IP
> > address-based reputation).
>
> Ok. But I still would like to know where in the stack the problem is.
> Right now, they are simply testing a release candidat
> Why do you care?
Because I'm actually trying to understand how things works and are best used.
On Thu, Mar 31, 2016, at 04:57 PM, Wietse Venema wrote:
> However the dnsblog client is stateless; it relies on caching in your local
> DNS resolver.
Okay, that's the part I missed.
Thanks.
Jason
I'm learning about whitelist scoring in postscreen_dnsbl_sites=
/dev/rob0 mentioned using these
postscreen_dnsbl_sites=
... BLACKLISTS ...
swl.spamhaus.org*-4
list.dnswl.org=127.[0..255].[0..255].0*-2
list.dnswl.org=127.[0..255].[0..255].1*-3
l
I'd like to understand postscreen's cache behavior a bit better than I do.
Looking at my logs for one example
Mar 29 18:25:28 mail01 postfix/postscreen[24234]: CONNECT from
[79.13.92.233]:64564 to [192.0.2.24]:25
Mar 29 18:25:28 mail01 postfix/dnsblog[24238]: addr 79.13.92.233 li
On Tue, Mar 29, 2016, at 09:54 AM, /dev/rob0 wrote:
> > and my goal is to block that & all OTHER mta hosts that have their
> > NS on *.synapp.io or just synapp.io (just in case)
>
> Hehe, this brings to mind an old spam war story. Sorry, but this
> might be of interest to this thread.
I've (
On Tue, Mar 29, 2016, at 08:29 AM, /dev/rob0 wrote:
> A client lookup looks up the client hostname (if forward-confirmed
> reverse DNS) and IP address (in any case.)
>
> A helo lookup looks up the client's hostname as it gave in the
> HELO/EHLO command.
>
> A sender lookup looks up the sender
Viktor
On Mon, Mar 28, 2016, at 08:03 PM, Viktor Dukhovni wrote:
> Sorry, that's:
>
> http://www.postfix.org/postconf.5.html#check_client_ns_access
Ugh. I should have just searched for 'ns_access'. Thanks.
I'm not 100% sure why it's a "client" rule instead of a "sender" rule. Looking
at
Viktor
On Mon, Mar 28, 2016, at 04:25 PM, Viktor Dukhovni wrote:
> main.cf:
> smtpd_client_restrictions =
> check_ns_access pcre:${config_directory}/ns-access.pcre
I'm working on setting this up.
When I use your example, in my logs I see
warning: unknown smtpd restriction: "check_ns
> Then block on the following
>
> 82.196.0.0/16
> 37.139.0.0/16
> 198.211.0.0/16
> 198.199.127.0/24
At this stage, that's harsh -- those are DigitalOcean blocks. Not that I'm a
fan of the 'flow' of email I see from them, but right now -- servers with NS @
synapp.io seems a good enough solution
On Mon, Mar 28, 2016, at 04:25 PM, Viktor Dukhovni wrote:
> ratineer.com. 600 IN NS kilmer-dns2.synapp.io
>
> main.cf:
> smtpd_client_restrictions =
> check_ns_access pcre:${config_directory}/ns-access.pcre
>
> smtpd_restriction_classes = no_mta_wk
>
>
Hi,
How would I match/block access to mail sent from MTAs that have FQDNs that
start with
mta-wk-*
it's not a header, it's not content, it's not an IP ...
but, it's clearly logged in my postfix logs
postfix.log:Mar 24 13:00:42 mail2 postfix/int01/smtpd[20932]: connect
from mta-wk
Re-reading the docs and my configs I caught an issue -- similarly named params
that I hadn't realized as being different.
If my main.cf I had
smtpd_recipient_restrictions =
reject_non_fqdn_recipient
reject_unauth_pipelining
reject_non_fqdn_recipient
I'm doing some more thinking about this, and trying to follow the flow of the
mail and the probes.
Starting at the front, right now I have a postscreen instance on 'mail1'.
It listens to inbound mail then passes mail to amavisd
[mail1.example.com]:25 inet n - n - 1 postscreen
-
Hello,
I'm learning how to get remote address verification working. My 'mail1' server
receives mail from the net, and checks on 'mail2' to see if the recipient is
valid.
I've got a question about error/dsn status for the rejections.
Right now I've got non-existent addresses being rejected, li
71 matches
Mail list logo
