g up.
>>
>>Unfortunately, I do not have any way to communicate with the client MTA
>>admins, so I'm shooting in the dark here.
>
>>Restarted postfix after these changes and triggered the remote client to
>>try again, but unfortunately, the same error happens. Same thin
Thanks for the reply, and the suggestions, please see below in-line.
On 2023-04-07 13:25:42, Viktor Dukhovni via Postfix-users wrote:
> On Fri, Apr 07, 2023 at 11:25:33AM -0400, micah via Postfix-users wrote:
>
>> I have a few remote hosts who cannot send me mail, and I'm trying to
>> determine
Laura Smith writes:
> Before jumping on the hobbyhorse of self-righthousness about refusing
> to use “whitelist”/“blacklist”, perhaps you would do well to spend a
> few minutes on your favourite search engine researching the entymology
> of such terms.
>
> The origin of blacklist, for example,
Kris Deugau writes:
> micah anderson wrote:
>> Allen Coates writes:
>>> The web page https://www.abuseat.org/faq.html (about half-way down the
>>> page)
>>> has an honest - and fairly recent - appraisal of a number of DNSBLs.
>>
>
Allen Coates writes:
> On 24/05/2020 23:22, micah anderson wrote:
>> We paid for access to spamhaus for a while, but they jacked up the
>> prices and now its far too expensive even for their non-profit rate.
>>
>> What RBLs do people find to be effective now days? I
Laura Smith writes:
> I should also add that you should not be afraid to pay for access. The
> good lists will (a) block you if you hammer them with high volumes of
> requests (b) save some of their better content (or new innovations)
> for their paid subscribers.
We paid for access to spamhaus
Jaroslaw Rafa writes:
> Dnia 27.02.2020 o godz. 07:02:10 Wietse Venema pisze:
>> > firewall for me. Additionally, what I didn't mention in my original post,
>> > it was eating up my resources a bit, and there was a noticeable server
>> > slowdown.
>>
>> In what respect? File system (logging),
Matus UHLAR - fantomas writes:
> welcome to the internet. Can be misconfigured client, spamware somewhere,
> scan, whatever. Firewalling those automatically is the only way to limit
> those messages.
I'm curious what kind of firewalling rules that people have come up with
to limit these. Are
Wietse Venema writes:
> micah anderson:
>> Eray Aslan writes:
>>
>> > On Wed, Dec 19, 2018 at 02:36:50PM -0500, Viktor Dukhovni wrote:
>> >> If there are no objections, I can change the default to "may" when
>> >> TLS is compiled in.
&
Eray Aslan writes:
> On Wed, Dec 19, 2018 at 02:36:50PM -0500, Viktor Dukhovni wrote:
>> If there are no objections, I can change the default to "may" when
>> TLS is compiled in.
>
> No objections for setting smtp_tls_security_level. Thanks for your
> effort.
I just wanted to circle back to
Viktor Dukhovni writes:
>> On Oct 11, 2019, at 10:19 AM, micah anderson wrote:
>>
>> I am aware of that, but I'm not asking specifically how to implement
>> this, I'm more trying to find out what really is the concern here with
>> enabling this,
"A. Schulze" writes:
> micah anderson:
>
>> If we want to try and respect MTA-STS, when doing STARTTLS, the sender
>> needs to send the right information in the TLS SNI (Server Name
>> Inidication) extension. An MTA-STS-honoring SMTP client expects to
If we want to try and respect MTA-STS, when doing STARTTLS, the sender
needs to send the right information in the TLS SNI (Server Name
Inidication) extension. An MTA-STS-honoring SMTP client expects to
validate the X.509 certificate of the receiving MTA, but that MTA might
be known by a dozen
"@lbutlr" writes:
> On 12 Apr 2019, at 08:46, micah anderson wrote:
>> he site https://hardenize.com provides relatively decent Email reports,
>> along with other reports. It checks a number of things including certs,
>> MTA-STS, TLS-RPT, DANE, SPF, DMARC, a
Scott Kitterman writes:
> On Friday, April 12, 2019 10:46:50 AM micah anderson wrote:
>> The site https://hardenize.com provides relatively decent Email reports,
>> along with other reports. It checks a number of things including certs,
>> MTA-STS, TLS-RPT, DANE, SPF, DMA
Viktor Dukhovni writes:
>> On Apr 12, 2019, at 10:46 AM, micah anderson wrote:
>>
>> I know that 'hardening postfix' threads have been posted here a number
>> of times, I've read them and I understand the recommendations if you
>> want to continue deliv
micah anderson writes:
> 2. Server suite preferences: they break down each preferred cipher
> selection for each TLS verison, and are unhappy about the cipher suite
> configuration being suboptimal, specifically that the forward secrecy
> ciphers (ECDHE or DHE) and authenticated enc
The site https://hardenize.com provides relatively decent Email reports,
along with other reports. It checks a number of things including certs,
MTA-STS, TLS-RPT, DANE, SPF, DMARC, and then also TLS. These are all
good checks and recommendations, with the exception of the TLS one, I do
not see
Scott Kitterman writes:
> On Saturday, April 06, 2019 04:55:58 PM Laura Smith wrote:
>> Hi,
>>
>> Am currently refreshing my perimeter mail infrastructure.
>>
>> The current state of affairs of DKIM signing looks pretty miserable!
>>
>> DKIMProxy seems to be abandonware since 2010
>>
>>
SH Development writes:
> I'm about at my wits end with Google.
>
> A couple of weeks ago, we had a user account get compromised. About
> 11,000 spam emails were sent through the account over a 24 hour period
> before we caught it and shut it down.
I know it doesn't help your current
Wietse Venema writes:
> Viktor Dukhovni:
>> On Wed, Dec 19, 2018 at 01:51:19PM -0500, Scott Kitterman wrote:
>>
>> > > So the real question is whether there is a non-trivial community
>> > > of users who:
>> > >
>> > > * Have no explit "smtp_tls_security_level" setting in their main.cf
>> >
Viktor Dukhovni writes:
> On Wed, Dec 19, 2018 at 01:51:19PM -0500, Scott Kitterman wrote:
>
>> > So the real question is whether there is a non-trivial community
>> > of users who:
>> >
>> > * Have no explit "smtp_tls_security_level" setting in their main.cf
>> > file.
>> >
>> > *
micah writes:
> Viktor Dukhovni writes:
>
>>> On Dec 6, 2017, at 8:08 PM, micah wrote:
>>>
>>> Is there any reason why postfix, when compiled with TLS, can simply set
>>> the default to 'may'?
>>
>> This is easy enough to implement, the only complication is
>> that the documentation would
"@lbutlr" writes:
> On Oct 24, 2018, at 09:19, Benny Pedersen wrote:
>>
>> do not disable tlsv1
>
> I couldn’t disagree more. TLSv1.2 has been out for a decade and there is no
> reason to be running v1 or v1.1. At all.
>
> I’ve been running with TLSv1.2 only for over a year.
How much email
In 2015, Viktor wrote an email detailing the current recommended TLS
settings[0].
Now that we are three years later, are these still the best settings? Is
there something better we can be recommending?
If anything, I think that 'smtp_tls_security_level = may' should be
recommended (it actually
Hello,
I tried to add a smtpd_reject_footer to submission and smtps as an
option in my master.cf:
submission inet n - n - - smtpd -o
smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_footer=\c
For further help, contact the support desk
smtps
ehlo,
tl;dr: Is there really no way in postfix to restrict what "From" headers
a user may specify?
For outgoing mail, we would like to restrict the "From" header to match
the address users SASL authenticate with, or is configured as an alias
in their account. We have setup
Hello,
I've configured check_sasl_access to be a sql map, like so:
proxy:mysql:/etc/postfix/checks/check_sasl_access.sql
and that check_sasl_access.sql file has the regular database DBI bits,
and then the following query:
query = SELECT CONCAT("PREPEND X-User-ID: ",
From my understanding of the way postfix currently operates, there is no
smtpd/stmp TLS setting that can be set that would provide a
configuration that would result in a more 'hardened' configuration,
without causing interoperability problems. If I am wrong, I'm very
interested in knowing where.
I'm running a busy server that is periodically experiencing problems
with tlsmgr, at various times (typically once a day at minimum), the
following appears in the logs:
Jun 16 07:34:40 willet postfix/smtp[24449]: warning: connect to private/tlsmgr:
Resource temporarily unavailable
Jun 16
Patrick Ben Koetter p...@state-of-mind.de writes:
* micah anderson mi...@riseup.net:
I'm running a busy server that is periodically experiencing problems
with tlsmgr, at various times (typically once a day at minimum), the
following appears in the logs:
Jun 16 07:34:40 willet postfix
Excerpts from wietse's message of Mon Nov 09 17:06:11 -0500 2009:
Micah Anderson:
I would like to reduce the mysql transport retry time (or perhaps the
proxymap retry time?), is there a variable that I can tweak down to
reduce the time between retries of mysql transport connection losses
Excerpts from wietse's message of Tue Nov 10 15:45:38 -0500 2009:
micah anderson:
If anything should retry the query, then it would be the mysql
client. The proxymap can't make such decisions (for example, it
makes no sense to retry after a read error from a local file
Excerpts from wietse's message of Tue Nov 10 17:22:57 -0500 2009:
micah anderson:
hosts = mysql-cluster1 mysql-cluster1
This repeats the query only if the session breaks. However, the
hosts are tried without delay, so this is unlikely to be a solution
for kernel panics
I would like to reduce the mysql transport retry time (or perhaps the
proxymap retry time?), is there a variable that I can tweak down to
reduce the time between retries of mysql transport connection losses?
I'm using mysql for transport_maps and virtual_mailbox_maps.
transport_maps =
35 matches
Mail list logo
