Take a look at your header file when using the VPN to email yourself. I
think what you want happens automatically.
Received: from [10.8.0.6] (unknown [MYIPADDRESS])
10.8.0.6 is the local IP space created by my VPN. But my IP address
also shows up, so hopefully a guru will chime in as to how this
Even with level encrypt the certificates are **NOT** verified which
means anyonymous chiphers are still used.
To verfiy peer certificates see:
http://www.postfix.org/TLS_README.html#client_tls_verify.
Or configure postfix smtp server to enforce clients to present a cert:
http://www.postfix.org/pos
Hi,
Can anyone tell me how to point postfix to a VPN connection? I have
setup a VPN listening at background on my Ubuntu and I want to point
postfix to that listening port whenever postfix try to connect to the
internet.
Thanks,
Yubin
Viktor
> >> What debug_peer_level would catch 'ESMTP SIZE=' and 'syntax errors in the
> >> sender address' issues? Only for the debug_peer_list table entries.
The default debug_peer_level (2) is sufficient, but even (1) is likely enough
to log the SMTP conversation (which is all you need here).
Viktor
On Mon, Jul 31, 2017, at 02:11 PM, Viktor Dukhovni wrote:
> (Note that's "aNULL:-aNULL:..." not "aNULL:!aNULL:...").
Yeah noticed that. Not clear what the diff is yet, but sticking with the
"aNULL:-aNULL" for this.
> This ensures that anon-DHE/anon-ECDHE ciphers are actually used when
> On Jul 31, 2017, at 4:09 PM, robg...@nospammail.net wrote:
>
>> What debug_peer_level would catch 'ESMTP SIZE=' and 'syntax errors in the
>> sender address' issues? Only for the debug_peer_list table entries.
>
> That seems to be only the debug level for smtpd right?
>
> Is there a different
> On Jul 31, 2017, at 4:05 PM, robg...@nospammail.net wrote:
>
> What debug_peer_level would catch 'ESMTP SIZE=' and 'syntax errors in the
> sender address' issues? Only for the debug_peer_list table entries.
>
> The docs read as 'increment'. I don't know yet if that's additive on top of
> so
> On Jul 31, 2017, at 4:55 PM, robg...@nospammail.net wrote:
>
> "why use "aNULL:-aNULL:" in Postfix default cipherlists?"
(Note that's "aNULL:-aNULL:..." not "aNULL:!aNULL:...").
This ensures that anon-DHE/anon-ECDHE ciphers are actually used when
mutually enabled and authentication is off at
I'm reading about ciphers.
Here
"why use "aNULL:!aNULL:" in Postfix default cipherlists?"
http://postfix.1071664.n5.nabble.com/why-use-quot-aNULL-aNULL-quot-in-Postfix-default-cipherlists-td83301.html
It talks about using anonymous ciphers when TLS policy is opportunistic == may.
I get that.
Am 31.07.2017 um 20:43 schrieb A. Schulze:
> seeing cert_subject + cert_issuer inside a milter may be an indicator of
> "trusted connection"
> and report my findings ...
as Viktor said:
a milter get issuer and subject only for connections SMTPD also log as "trusted"
On untrusted and anonymous
> What debug_peer_level would catch 'ESMTP SIZE=' and 'syntax errors in the
> sender address' issues? Only for the debug_peer_list table entries.
That seems to be only the debug level for smtpd right?
Is there a different domain-specific parameter that sets log level for
tls@smtpd?
Hi Viktor
On Mon, Jul 31, 2017, at 12:45 PM, Viktor Dukhovni wrote:
> The main effect of "-v" in most cases is to obscure the relevant logs
> with lots of noise from the irrelevant logs.
No kidding!
> Policy rejection of the "MAIL FROM:" is covered
> by routine (non-verbose) logging.
Ok so I d
> On Jul 31, 2017, at 1:39 PM, robg...@nospammail.net wrote:
>
>> Find out why you're rejecting the client's "MAIL FROM:" command.
>
> Huh. No idea what's causing the sender's FROM to be rejected -- should be
> an OK address.
>
>> This would typically be logged
>
> So it SHOULD be logged.
>
Am 31.07.2017 um 20:16 schrieb Wietse Venema:
> I looked at the code for the cleanup daemon which is TLS unaware.
> So the corrected reply would be that we may have partial support.
Hello,
thanks to all. I'll give Viktor's point a try:
seeing cert_subject + cert_issuer inside a milter may be a
Viktor Dukhovni:
>
> > On Jul 31, 2017, at 10:55 AM, Wietse Venema wrote:
> >
> > Postfix does not implement TLS-related Milter macros. That would
> > require some new code. Currently, the cleanup daemon does not know
> > anything about TLS, so getting that info from the smtpd(8) process
> > wou
Hi Viktor
On Mon, Jul 31, 2017, at 10:30 AM, Viktor Dukhovni wrote:
> > Jul 23 06:22:21 maryland postfix/handoff/smtpd[7668]: connect from
> > smtp10.ymem.net[24.73.102.76]
> > Jul 23 06:22:22 maryland postfix/handoff/smtpd[7668]: disconnect from
> > smtp10.ymem.net[24.73.102.76] ehlo=1
Hi friends,
I would like to know how automate the users and domains list between primary
and backup MX server, where the primary (and secondary) mail server use
mysql for each user and domain list (and create so an MX backup server that
it does not become a "backscatter mail"!)
I've seen this date
> On Jul 31, 2017, at 1:17 PM, robg...@nospammail.net wrote:
>
> Jul 23 06:22:21 maryland postfix/handoff/smtpd[7668]: connect from
> smtp10.ymem.net[24.73.102.76]
> Jul 23 06:22:22 maryland postfix/handoff/smtpd[7668]: disconnect from
> smtp10.ymem.net[24.73.102.76] ehlo=1 mail=0/1
I run Postfix 3.3.
My inbound mail is working great, except for a few 'newsletters' I sign up for.
>From a few "legit" newsletter senders, i.e. those that I opt-in with, I get
CONNECT/DISCONNECT
pairs in my logs. And of course no delivery.
In the logs I get these
Jul 23 06:22
> On Jul 31, 2017, at 12:08 PM, Claus Assmann
> wrote:
>
> On Mon, Jul 31, 2017, Viktor Dukhovni wrote:
>
>> I don't know what milters expect to find in "{cert_issuer}" and
>> "{cert_subject}". The CN or the full DN (and if so in what
>> encoding). We provide CNs, but perhaps Sendmail provid
On Mon, Jul 31, 2017, Viktor Dukhovni wrote:
> I don't know what milters expect to find in "{cert_issuer}" and
> "{cert_subject}". The CN or the full DN (and if so in what
> encoding). We provide CNs, but perhaps Sendmail provides
> DNs?
It's in the fine documentation (op.*)
${cert_issue
> On Jul 31, 2017, at 10:55 AM, Wietse Venema wrote:
>
> Postfix does not implement TLS-related Milter macros. That would
> require some new code. Currently, the cleanup daemon does not know
> anything about TLS, so getting that info from the smtpd(8) process
> would also require some new code.
> On Jul 31, 2017, at 9:06 AM, A. Schulze wrote:
>
> Postfix smtp server may classify incoming TLS sessions as anonymous,
> untrusted and trusted.
> (http://www.postfix.org/FORWARD_SECRECY_README.html#status)
>
> Is it possible to access this information from within a milter?
Some TLS informa
A. Schulze:
> Hello,
>
> postfix smtp server may classify incoming TLS sessions as anonymous,
> untrusted and trusted.
> (http://www.postfix.org/FORWARD_SECRECY_README.html#status)
>
> Is it possible to access this information from within a milter?
>
> I did not found such funktionallity on
>
Postfix 3.2.2
Post upgrade, I'm revisiting my configuration to be sure I'm taking advantage
of current features relative to my old server.
I'm still using 2 cleanup services , pre-cleanup before the content_filter and
the regular cleanup after-filter.
I was using Patrick Koetter's current p
On Mon, Jul 31, 2017 at 04:46:36AM -0700, fugeeohu wrote:
> I had to remove permit_sasl_authenticated from smtpd_sender_restrictions
> The new error is 4.3.0 Error: queue file write error
Who told you that you are not allowed to look into the logs?
There will be some more information.
Bastian
-
Hello,
postfix smtp server may classify incoming TLS sessions as anonymous, untrusted
and trusted.
(http://www.postfix.org/FORWARD_SECRECY_README.html#status)
Is it possible to access this information from within a milter?
I did not found such funktionallity on
http://www.postfix.org/MILTER_RE
On Mon, 31 Jul 2017, Matus UHLAR - fantomas wrote:
On 31.07.17 09:16, Tomas Macek wrote:
Hello, our system is sometimes under attack of spammers using
"NOTIFY=SUCCESS" param in "rcpt to: " header. And because of a random
From address, the DSN message obviously goes to an nonexistent server
I had to remove permit_sasl_authenticated from smtpd_sender_restrictions
The new error is 4.3.0 Error: queue file write error
--
View this message in context:
http://postfix.1071664.n5.nabble.com/no-sasl-listener-on-587-clients-can-t-send-mail-tp91609p91632.html
Sent from the Postfix Users mail
Matus UHLAR - fantomas:
> If filter was able to strip NOTIFY=, we'd have fine control over when to
> send notifications...
There is an example that modifies DSN commands in
http://www.postfix.org/postconf.5.html#smtpd_command_filter
Wietse
Tomas Macek:
> Hello, our system is sometimes under attack of spammers using
> "NOTIFY=SUCCESS" param in "rcpt to: " header. And because of a random From
> address, the DSN message obviously goes to an nonexistent server
> or user.
>
> I've read the "Restricting the scope of "success" notificat
On 31.07.17 09:16, Tomas Macek wrote:
Hello, our system is sometimes under attack of spammers using
"NOTIFY=SUCCESS" param in "rcpt to: " header. And because of a random
From address, the DSN message obviously goes to an nonexistent server
or user.
I've read the "Restricting the scope of "suc
On 30.07.17 15:17, fugeeohu wrote:
What's wrong smtpd_tls_auth_only=yes I see the default is no The explanation
is that it refuses to accept sasl authentication over an insecure connection
I dunno what means I thought sasl makes an insecure connection secure but I
sasl is just authentication la
Hello, our system is sometimes under attack of spammers using
"NOTIFY=SUCCESS" param in "rcpt to: " header. And because of a random From
address, the DSN message obviously goes to an nonexistent server
or user.
I've read the "Restricting the scope of "success" notifications" topic at
http://w
34 matches
Mail list logo
