On 10/16/20 11:54 AM, Viktor Dukhovni wrote:
If the custom 4XX response is not a hard requirement, the simplest
solution is:
main.cf:
# To defer all email, change to: lunchtime = y
lunchtime =
smtpd_recipient_restrictions =
${lunchtime?defer_if_permit
i've set up two postfix instances on 2 separate machines
frontend
backend
'backend' gets user data via postfixadmin/sqlite3 DB
i've setup address verification between the instances
on mail receipt @ 'frontend', a verify probe is sent to 'backend'.
if 'exists', then mail is sent
Demi M. Obenour:
> Should I submit another patch? In addition to adding
> local_sender_login_maps, I have fixed what appeared to be a bug in
> the current postdrop and sendmail commands: root and $mail_owner were
> not automatically allowed to submit mail. Since this is inconsistent
> with simila
PGNet Dev:
> i've set up two postfix instances on 2 separate machines
>
> frontend
> backend
>
> 'backend' gets user data via postfixadmin/sqlite3 DB
>
> i've setup address verification between the instances
>
> on mail receipt @ 'frontend', a verify probe is sent to 'backend'.
> if
Rich Wales:
> > Why do you believe that your server is an open relay, as in, it
> > will forward messages FROM spammers TO remote destinations.
> > Wietse
>
> Because it *is* accepting messages from outsiders (spammers) and is
> using my server to relay those messages to remote destinations. It w
On 10/17/20 1:23 AM, Viktor Dukhovni wrote:
>> On Oct 17, 2020, at 3:09 AM, Demi M. Obenour wrote:
>>
>>> The practical limit to the deferred queue size is therefore ~2 days of
>>> throughput, and depends heavily on the per-delivery latency. If
>>> delivery failures are slow (tarpitting or otherw
Thank you all. This is how I fixed it (after Bill Cole's email): I needed
to substitute envelope (MAIL FROM:) to match my address, but the message
(along with it's headers) shouldn't be touched.
sender_canonical_classes = envelope_sender # Only change envelope, not body
sender_canonical_maps = r
On 10/17/20 11:34 AM, Wietse Venema wrote:
> Demi M. Obenour:
>> Should I submit another patch? In addition to adding
>> local_sender_login_maps, I have fixed what appeared to be a bug in
>> the current postdrop and sendmail commands: root and $mail_owner were
>> not automatically allowed to submi
Just FYI, GMail marked this mail as spam.
Demi
OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
On Sat, Oct 17, 2020 at 02:05:57PM -0400, Demi M. Obenour wrote:
> > Postfix 3.4 and later grudgingly do some event-driven work because
> > TLS connection reuse with OpenSSL is not possible out-of-process.
> > So the tlsproxy(8) process context switches between multiple TLS
> > connections, but th
At 17 October, 2020 Demi M. Obenour wrote:
> > Postfix is not an HTTP server handling tens to hundreds of thousands of
> > requests
> > per second, and does not benefit from the optimisations needed for those
> > kinds
> > of workloads. Premature optimisations that sacrifice robustness and
>
Demi M. Obenour:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> On 10/17/20 11:34 AM, Wietse Venema wrote:
> > Demi M. Obenour:
> >> Should I submit another patch? In addition to adding
> >> local_sender_login_maps, I have fixed what appeared to be a bug in
> >> the
Demi M. Obenour:
> > BTW I realized that I swapped the semantics of smtpd_sender_login_maps
> > (a mapping from sender address to the login names that are allowed
> > to use that sender address) when we were discussing the postdrop
> > feature (a mapping from login name to the sender addresses that
Dnia 17.10.2020 o godz. 18:25:13 Wietse Venema pisze:
> For the port
> 25 MTA-to-MTA service one can then reject all mail from a remote
> site that claims to be from a local user.
That's not a good idea. Assume domain.com is configured that way and some
user on a completely different domain (us...
Jaroslaw Rafa:
> Dnia 17.10.2020 o godz. 18:25:13 Wietse Venema pisze:
> > For the port
> > 25 MTA-to-MTA service one can then reject all mail from a remote
> > site that claims to be from a local user.
>
> That's not a good idea. Assume domain.com is configured that way and some
> user on a compl
On 10/17/20 6:42 PM, Wietse Venema wrote:
> Jaroslaw Rafa:
>> Dnia 17.10.2020 o godz. 18:25:13 Wietse Venema pisze:
>>> For the port
>>> 25 MTA-to-MTA service one can then reject all mail from a remote
>>> site that claims to be from a local user.
>>
>> That's not a good idea. Assume domain.com is
Hello.
What is the difference between these two types?
Thank you.
Ilya.
On 10/17/20 6:25 PM, Wietse Venema wrote:
> Demi M. Obenour:
>>> BTW I realized that I swapped the semantics of smtpd_sender_login_maps
>>> (a mapping from sender address to the login names that are allowed
>>> to use that sender address) when we were discussing the postdrop
>>> feature (a mapping
On 17 Oct 2020, at 20:19, IL Ka wrote:
> Hello.
>
> What is the difference between these two types?
> Thank you.
>
> Ilya.
You can get this from 'man 5 master':
unix The service listens on a UNIX-domain stream socket and is
accessible for local clients only.
[...]
pass The service
> /Show evidence (logging) and turn of verbose logging. Wietse/
OK, here is the message header for one of the spam e-mails (which did
not get deleted during my mass cleanup efforts because a copy was saved
in my amavisd-new quarantine database):
X-Envelope-From:
X-Envelope-To:
X-En
Sorry, when I said "chronologically last 'Received:' line" in my earlier
e-mail, I meant to say "chronologically first (physically last)". Mea
culpa.
Rich Wales
ri...@richw.org
On Sat, Oct 17, 2020 at 08:41:25PM -0700, Rich Wales wrote:
> Received: from memoryalpha.richw.org ([127.0.0.1])
> by localhost (memoryalpha.richw.org [127.0.0.1]) (amavisd-new, port
> 10024)
> with ESMTP id D0t9j6VORyNH for ;
> Thu, 15 Oct 2020 14:48:06 -0700 (PDT)
>
> No, it says no such thing. It says the EHLO name was [154.91.34.144],
> the client IP was however 127.0.0.1. It seems you have some sort of
> proxy or NAT in place that masks the real external IP address, making
> all connections appear to originate from 127.0.0.1. That would sure
> explain
On Sat, Oct 17, 2020 at 09:14:50PM -0700, Rich Wales wrote:
> Thanks. I was actually thinking something of the sort myself -- my
> server is indeed behind a separate firewall appliance.
>
> However, other e-mail (such as your recent reply to my inquiry) is NOT
> exhibiting this same NAT/proxy ad
24 matches
Mail list logo
