There is currently a similar thread on "mailop" mailing list about
connections from MS to *submission* ports, that connect, do valid AUTH
(using proper credentials!) and then hang up.
People in that thread suspect that this behavior might be associated with
connections from Outlook mobile app bei
BTW I explicitly allow mail from their IP ranges at postscreen level:
...
#outlook.com
40.92.0.0/15permit
40.107.0.0/16 permit
52.100.0.0/14 permit
104.47.0.0/17 permit
they published some more ranges but when I checked, I haven't noticed mail from
oth
OK mail from outlook does make it's way thru; e.g., since Monday,
xzegrep "250 2.0.0 Queued as.*outbound.protection.outlook.com"
/var/log/postfix/postfix.log | wc -l
4343
Isn't that outbound mail*to* Microsoft-hosted domains? I wouldn't
expect that to appear in logs of incoming ma
There is no protection you can add to prevent this
fair enuf
other than firewalling them completely.
the wishful-thinking of fw'ing MS's entire ASN has crossed my mind more than
once ;-)
Why do they do this? Only they know.
if they do, they certainly don't respond to @support/etc inqui
my "BFFs" @ M$'s *.outlook.com have decided over the last month or so to send
many 10K's of these
2023-08-14T13:11:53.782611-04:00 svr01 postfix/postscreen[27910]:
CONNECT from [52.101.56.17]:32607 to [209.123.234.54]:25
2023-08-14T13:11:59.860098-04:00 svr01 postfix/postscreen[
Consider (after carefully reading over the docs explaining the required
ordering of the content) switching to consolidated preferred syntax:
smtpd_tls_chain_files =
>> This feature is available in Postfix 3.4 and later.
that one snuck by me :-/
convenient, tho, thx!
No tool. J
That'd then be the file to analyse:
# tshark -nr /tmp/tls.pcap -V ssl
thx for the ez tutorial
after the key file cleanup,
...
Untrusted TLS connection established from
esa.hc2802-61.iphmx.com[68.232.155.227]: TLSv1.2 with cipher
ECDHE-RSA-AES128-GCM-SHA256
...
This explain
one'd hope that banks and hospitals might be a bit more up-to-date on their end.
after the key file cleanup,
...
Untrusted TLS connection established from
esa.hc2802-61.iphmx.com[68.232.155.227]: TLSv1.2 with cipher
ECDHE-RSA-AES128-GCM-SHA256
...
seems, in fact, EC-ready
As background, the RELEASE_NOTES for 3.8 mention:...>>
postfix/psint/smtpd[27820]:
esa.hc2802-61.iphmx.com[139.138.32.157]: TLS cipher list
"aNULL:-aNULL:HIGH:MEDIUM:!SEED:!IDEA:!3DES:!RC2:!RC4:!RC5:!kDH:!kECDH:!aDSS:!MD5:+RC4:@STRENGTH:!aNULL"
yep
Which is most of the above, but you
why?
not my own server/config
Can you explain how each of these is better than the Postfix defaults?
all but two _are_ at defaults
postconf -n | grep -i tls | grep -i cipher | sort
@D smtpd_tls_ciphers = medium
@D smtpd_tls_exclude_ciphers =
@D
in
postconf mail_version
mail_version = 3.8.1
i just caught the following TLS error in postfix logs,
2023-08-12T09:33:07.064713-04:00 cmx0024 postfix/postscreen[27816]:
cache lmdb:/var/lib/postfix/postscreen_cache full cleanup: retained=0 dropped=0
entries
On Thu, Aug 6, 2015, at 10:22 AM, Chris Adams wrote:
> Those are dbl response codes, not zen. You are mixing the two up
And you'd be correct! pebkac.
thanks.
Some time ago, I'd cribbed the following postscreen dnsbl weights from an
experienced users' post ... iirc, it was on this list
...
postscreen_dnsbl_threshold = 5
postscreen_dnsbl_sites =
b.barracudacentral.org=127.0.0.2*7
zen.spamhaus.org=127.0.0.[10;1
On Mon, Jul 6, 2015, at 08:18 PM, Noel Jones wrote:
> I'm done providing free consulting for your system. Best wishes.
Back to this again, are we? Petuiant drama's really quite unnecessary. Not a
single solitary soul has twisted your arm to participate.
Best wishes.
I'm walking through a week's worth of "leaks" through my filters etc., closing
the holes.
Most have been clear enough to trace & remediate.
This one has me a bit stymied. I'm not sure I have enough info to make out
what's in fact going on.
I'm seeing 2 different IPs in play, and can't unwind
On Mon, Jun 29, 2015, at 09:32 PM, Noel Jones wrote:
> When mail is discarded, no one is notified. From the end-user's
> point of view -- both the sender and receiver -- the mail is
> silently lost, and mail is unreliable.
Although I find users tend to squeak if the server isn't trashing "known
On Mon, Jun 29, 2015, at 08:55 PM, Peter wrote:
> > I continue to waffle re: the advantages/disadvantages of moving clamav &/or
> > SA postqueue. I've found bits-and-pieces of both pro & con arguments, but
> > nothing yet that's tilted strongly one way or the other.
>
> What I do ... and reco
On Mon, Jun 29, 2015, at 08:23 PM, Noel Jones wrote:
> > That DISCARD action is logged in the amavisd logs, but occurs silently from
> > Postfix's perspective -- it's not notified, and does not log the message
> > disposition in its log.
> >
> This is correct. From postfix's perspective, the mes
I've amavisd+spamassassin setup as a post-queue content-filter.
If a message PASSes postscreen+smtpd_mumble_restrictions, it's handed off to
amavisd+SA for content analysis.
Currently, amavisd is configured to 'D_DISCARD' mail that scores above a
specified level. It works as intended.
That DI
On Sat, Jun 27, 2015, at 12:37 PM, Viktor Dukhovni wrote:
> On Sat, Jun 27, 2015 at 12:34:06PM -0700, PGNd wrote:
>
> > > turn off the postmaster notices.
> >
> > To what specifically are you referring? My testmail was TO my postmaster
> > address, so we see
On Sat, Jun 27, 2015, at 10:21 AM, Viktor Dukhovni wrote:
> The Postfix logs will contain more specific details. Always look
> there,
Certainly. Poking at it now.
> turn off the postmaster notices.
To what specifically are you referring? My testmail was TO my postmaster
address, so we see
On Sat, Jun 27, 2015, at 08:18 AM, Steve Jenkins wrote:
> And now that OpenDMARC can use libspf2, I don't use a separate SPF checker
> in my Postfix setup. Just running OpenDKIM and OpenDMARC milters.
Good point.
Unfortunately, after rebuilding opendmarc with spf enabled, using libspf2, on
exe
On Sat, Jun 27, 2015, at 01:35 AM, A. Schulze wrote:
> just answerd on opendmarc-users but for reference here too:
> opendmarc defaults to ignore connections from localhost.
That was it. Obvious, now ...
On received messages,
...
DMARC-Filter: OpenDMARC Filter v1.3.1 mailhost..com 73D121
On Fri, Jun 26, 2015, at 07:02 PM, Benny Pedersen wrote:
> i forgot to tell remove non_smtpd_milters, since it is not used in smtpd
> listners
Thanks for the cleanup. Although, no add'l effect on the issue.
> > milter8_abort: skip milter inet:[127.0.0.1]:8893
> > disconnect event to all milte
On Fri, Jun 26, 2015, at 06:12 PM, Benny Pedersen wrote:
> change smtpd_milters= to be inet:[127.0.0.1]:8893 so it does not use
> ipv6 there, this should all needed
Did that. Unfortunately, there's no change in behavior or logs, other than the
reference, now, to 127.0.0.1 specifically,
...
m
I've added an opendmarc milter to a service
[127.0.0.1]:10031 inet n-n-- smtpd
-o syslog_name=postfix/postQ-rcv
>-o milter_protocol=6
>-o smtpd_milters=inet:localhost:8893
>-o non_smtpd_milters=inet:localhost:8893
On Tue, Jun 23, 2015, at 08:07 AM, Noel Jones wrote:
> You have it backwards.
>
> relay_domains = lmdb:/etc/postfix/relay_transports
> transport_maps =
>lmdb:/etc/postfix/relay_transports
>lmdb:/etc/postfix/external_transports
>
> Note the use of two transport_maps entries; one for the
In config, I've defined allowed relay_domains
/main.cf
...
relay_domains = 1.com
2.com
...
n.com
and also use
transport_maps=lmdb:/u
On Sun, Jun 21, 2015, at 08:19 PM, Noel Jones wrote:
> For local addresses, use an alias maps entry to pipe the mail to a
> program during local delivery.
>
> main.cf
> alias_maps = hash:/path/aliases
>
> # aliases
> spam: | /path/spam
> ham: | /path/ham
It's made no difference here; still
On Sun, Jun 21, 2015, at 03:15 PM, PGNd wrote:
> The link references will surely provide the solution; just not obvious quite
> yet.
Attempting to design a config for mail sent from backend valid user
(us...@1.com) to 'spam@' address on frontend, specifically to
"sp
On Sat, Jun 20, 2015, at 04:15 PM, Noel Jones wrote:
> > should do the trick. (?)
> Yes, that should work as expected.
> > Still ok here?
> That's fine. This doesn't have any direct effect on rejecting unknown users.
Appreciate the confirmations.
> > Suggest that I need the spam.1234@ and ha
On Fri, Jun 19, 2015, at 06:44 PM, Noel Jones wrote:
> You can control it with a check_recipient_access map in place of
> your blanket reject_unverified_recipient.
Ah.
My goal is:
-- for {spam,ham}.1...@mail..com accept & pipe to FILTER
'sa-spam'/'sa-ham', respectively
--
I've a postfix frontend instance that
-- relays only for specific domains
-- uses remote address verification
to a postfix backend.
Frontend config includes
/main.cf
myhostname= mailhost..com
mydomain = mail..com
> On Fri, Jun 19, 2015, at 07:56 AM, Viktor Dukhovni wrote:
Thanks for digging into this.
> As soon as I saw this, I said to myself "it'll loop". Not
> surprisingly, it does.
I'll trust the stmt, and need to stare at the flow more closely to be able to
come to the same immediate conclusion.
I've setup a Postfix store & forward frontend gateway that forwards all mail
for valid domains (DDD1.com -> DDDN.com) to a Postfix backend.
-- The frontend serves as an outbound smarthost for all backend domains.
-- Transport, and recipient verification, TO the backend, and all smarthost
sends F
On Thu, Jun 18, 2015, at 09:00 AM, Bill Cole wrote:
> It varies from site to site, but if you have the wrong sort of target
> domains you can see things like ...
...
> A tool like fail2ban may not be able to act fast enough to cut off
> the first attack from bots acting like Cutwail, but if con
I've a 2-postfix setup.
The frontend
is open to 'net only on port 25
receives email for my domains from 'net
applies restrictions
forwards to backend if PASS
serves as outbound SMARTHOST to backend; accepts no direct submission
generates log entries
> postscreen is one layer in a multi-layer defense. It does not have
> to stop all unwanted email. That is what the other layers are for.
Certainly. That does not warrant blindly stacking layers upon one another
simply because one can.
There are certainly layers that postscreen clearly renders
The introduction of Postfix's postscreen into edge mail-defense, particularly
with a well thought out set of DNSBLs has fairly dramatically cut down on my
spam rates.
Additional pre- & post-queue filtering downstream of postscreen is down to a
easily manageable trickle.
Prior to postscreen, fa
On Sat, Jun 13, 2015, at 08:41 PM, Noel Jones wrote:
> Your reading is essentially correct. Postfix does not support "if
> this lookup fails, look there instead".
I had hoped that some variant of the available sequential lookups through
multiple sources might do the trick; seems not.
Then I'll
On Sat, Jun 13, 2015, at 05:09 PM, Wietse Venema wrote:
> Postfix implements multiple layers of defense to block mail: the
> order of these is postscreen, smtpd_mumble_restrictions, milter
> SMTP command inspection, smtpd_proxy_filter, header/body_checks,
> milter header/body inspection, content_
On Sat, Jun 13, 2015, at 03:45 PM, Wietse Venema wrote:
> > Can I similarly control the relative order of execution of the spf
> > policy milters and the prequeue amavis proxy filter?
>
> Postfix documentation does not promise that this is possible, therefore it is
> not supported.
There's a fau
With config
relay_recipient_maps =
address_verify_map = ${dbtype}:${datadir}/verify_cache
address_verify_transport_maps =
static:relay-remote:[internal..com]:25
relay_transport = relay-remote:[internal..com]:10587
remote recipient verification, and subsequ
I'm moving some msg filtering prequeue
/master.cf
smtp inet n - n - 1 postscreen
ps-handoff pass - - n - - smtpd
-o syslog_name=postfix/in-from-ext
-o smtpd_proxy_filter=127.0.0.1:10001
On 06/13/2015 06:06 AM, Viktor Dukhovni wrote:
> If the expected maximum downtime for the backend system is well
> below the positive cache time on the frontend, you can ignore the
> possibility of backend downtime. Once the cache is primed with
> all the addresses that routinely receive email, the
On Fri, Jun 12, 2015, at 09:33 PM, Noel Jones wrote:
> I don't intend to insult you, and apologize if you interpreted it
> that way. If you have a question, please ask it.
Thanks. Moving on.
Goal
I don't want to lose mail if the back-end server connection is offline
for an extended pe
On Fri, Jun 12, 2015, at 05:57 PM, Noel Jones wrote:
> I think a careful reading of
> http://www.postfix.org/ADDRESS_VERIFICATION_README.html
> will answer all your questions.
Actually, no.
It was a careful reading of that document, including each of the references
that you've made -- as pointed
The general gist of my lengthy question is --
I have 2 physically separated Postfix instances, the 1st uses remote address
verification queries agains the 2nd.
What happens when the connection between them goes down?
Currently, the remote postfix instance provides
postscreen -- smtpd_*_
On Wed, Jun 10, 2015, at 08:15 PM, Viktor Dukhovni wrote:
> You should not need that. You can safely replace "smtpd_tls_req_ccert"
> with "smtpd_tls_ask_ccert". Clients that don't present a certificate
> will be denied access anyway.
> Also IIRC your logging reported
> "Trusted" client connect
On Wed, Jun 10, 2015, at 06:53 PM, Viktor Dukhovni wrote:
> > -o permit_tls_clientcerts=yes
>
> No such parameter.
Yes, caught that. It's correctly in
-o smtpd_relay_restrictions=permit_tls_clientcerts,reject
Not clear how I ended up with that. Gone now.
> > -o relay_clientce
On Wed, Jun 10, 2015, at 03:19 PM, A. Schulze wrote:
> > openssl x509 -pubkey -noout -in /etc/ssh/mail/commercial.crt |
> > openssl pkey -pubin -outform DER | openssl dgst -sha1 -c
>
> take the output of "openssl x509 -sha1 -fingerprint -noout -in cert.pem"
To what end? That will extract the
I'm next configuring a service to provide outbound smarthosting to a local
server. As with several of my other services, the goal is to use TLS cert
check/auth only, no SASL.
Sending a test message via the local server, log at the smarthost shows message
reject "Recipient address rejected: Acce
> Yes, the key question is what's in the server certificate. You'll
> want "match=". And if you're using the
> policy table, you don't also need "smtp_tls_security_level=secure",
> the policy table preempts that.
Back to
CLIENT/master.cf
-o smtp_tls_CAfile=/etc/ssl/mai
On Tue, Jun 9, 2015, at 07:57 PM, Viktor Dukhovni wrote:
> This requires some operational discipline, but avoids trusting third parties.
If I also control the CA, which in this case I do, I gather that point is moot.
Still, the FP method seems cleaner in this case.
> But you're still not authenticating the server. For that you'll need:
> smtp_tls_security_level=secure so that the client verifies the server
> hostname also and
> refuses to proceed when authentication fails.
A simpler alternative for my case may be
-o smtp_tls_CAfile=/etc
On Tue, Jun 9, 2015, at 06:25 PM, Viktor Dukhovni wrote:
> This sets the client's certificate chain file, not its list of trusted CAs.
Misunderstood, now clear.
> But you're still not authenticating the server. For that you'll need:
> smtp_tls_security_level=secure so that the client verifies t
> On Tue, Jun 9, 2015, at 05:08 PM, Viktor Dukhovni wrote:
Zeroing in on
> This means that the server's certificate is not issued by a CA trusted by the
> client
In configs
CLIENT/master.cf
...
relay-remoteunix--n--smtp
I'm forwarding specific mail from a remote Postfix instance to a local one.
I'm switching from SASL auth to high-encryption tls cert auth'd connection.
It works to the extent that
(1) connections without the TLS cert in place are rejected
(2) a Trusted TLS connection is establish
58 matches
Mail list logo
