On Wed, Jan 11, 2023 at 04:17:31PM -0800, Dan Mahoney
wrote:
> The idea of a command line program you can pipe a mail to with a
> command line arg that lets you specify a list of recipients in a
> textfile, and have new messages injected, cleanly, with stripped
> headers, into the queue, feels l
greetings,
Do you know why many providers even those big ones didn't implement SRS when
forwarding email to other ESP?
for instance, outlook.com, mail.ru, and even google domains who has specificed
email forwarding feature for their domain users, don't have SRS enabled in
their forwarded messa
> Do you know why many providers even those big ones didn't implement SRS when
> forwarding email to other ESP?
>
> for instance, outlook.com, mail.ru, and even google domains who has
> specificed email forwarding feature for their domain users, don't have SRS
> enabled in their forwarded messa
DL Neil wrote in
<2796fd95-6554-f0ef-3ad9-1eb1e99c3b36@rangi.cloud>:
|On 12/01/2023 13.16, Viktor Dukhovni wrote:
|> On Thu, Jan 12, 2023 at 12:46:03PM +1300, DL Neil wrote:
...
|Experiment:
|- from an external address and server, send a message to the 'list' account
|- postfix receives the
Hello.
I am trying to find an error for the lost connection error. I tried several
different sources but don't seem to make any progress.
Thank you for pointing me into the right direction.
Jan 12 14:01:02 home postfix/submission/smtpd[7046]: connect from
unknown[10.5.2.1]
Jan 12 14:01:02 home po
On Thu, Jan 12, 2023 at 03:51:35PM +0100, Wolfgang Paul Rauchholz wrote:
> I am trying to find an error for the lost connection error. I tried
> several different sources but don't seem to make any progress.
What do you know about the SMTP client system?
> Thank you for pointing me into the righ
Since I am using SPF as a validation method, the non-srs messages from those
big providers will have possibility to break SPF and be rejected by our systems.
Do you reject based on solely the SPF result? It would be better to use DMARC,
have SPF only create the auth header and not reject, then
Le jeu. 12 janv. 2023, 17:15, a écrit :
> > Since I am using SPF as a validation method, the non-srs messages from
> those big providers will have possibility to break SPF and be rejected by
> our systems.
>
> Do you reject based on solely the SPF result? It would be better to use
> DMARC, have S
Emmanuel Fust?:
> Le jeu. 12 janv. 2023, 17:15, a ?crit :
>
> > > Since I am using SPF as a validation method, the non-srs messages from
> > those big providers will have possibility to break SPF and be rejected by
> > our systems.
> >
> > Do you reject based on solely the SPF result? It would be
Le 12/01/2023 à 17:51, Wietse Venema a écrit :
Emmanuel Fust?:
Le jeu. 12 janv. 2023, 17:15, a ?crit :
Since I am using SPF as a validation method, the non-srs messages from
those big providers will have possibility to break SPF and be rejected by
our systems.
Do you reject based on solely
Le 12/01/2023 à 18:17, Emmanuel Fusté a écrit :
Le 12/01/2023 à 17:51, Wietse Venema a écrit :
Emmanuel Fust?:
Le jeu. 12 janv. 2023, 17:15, a ?crit :
Since I am using SPF as a validation method, the non-srs messages
from
those big providers will have possibility to break SPF and be
rejecte
Charles Sprickman:
> I'm thinking that for my personal mail server I would like to stop showing
> the world the IP that I'm sending email from, for various reasons, but mostly
> privacy.
>
> I see lots of sketchy options out there using header checks, but I'd ideally
> like to not just strip ou
No SPF is OK, but as long as the domain of RFC822 MAIL FROM address has a SPF,
this SPF must pass.
DMARC will pass as long as either SPF or DMARC passes.
DMARC will still pass if SPF fails and DKIM passes.
I think you might be misinterpreting what you are reading.
Regardless, in practice in th
Perhaps it would be sensible for Postfix itself to provide a
configuration parameter that somehow lets you conceal or replace the
sending IP/hostname of submitted mail?
My solution...
main.cf:
smtp_header_checks = pcre:/etc/postfix/header_checks_smtp
/etc/postfix/header_checks_smtp:
/
On Thu, Jan 12, 2023 at 01:49:33PM -0500, post...@ptld.com wrote:
> My solution...
>
> main.cf:
> smtp_header_checks = pcre:/etc/postfix/header_checks_smtp
>
>
> /etc/postfix/header_checks_smtp:
> /^Received:/ IGNORE
> /^X-Originating-Ip:/ IGNORE
That's a rather radi
> On Jan 12, 2023, at 2:40 PM, Viktor Dukhovni
> wrote:
>
> On Thu, Jan 12, 2023 at 01:49:33PM -0500, post...@ptld.com wrote:
>
>> My solution...
>>
>> main.cf:
>> smtp_header_checks = pcre:/etc/postfix/header_checks_smtp
>>
>>
>> /etc/postfix/header_checks_smtp:
>> /^Received:/
Dnia 12.01.2023 o godz. 13:49:33 post...@ptld.com pisze:
> My solution...
>
> main.cf:
> smtp_header_checks = pcre:/etc/postfix/header_checks_smtp
>
>
> /etc/postfix/header_checks_smtp:
> /^Received:/ IGNORE
> /^X-Originating-Ip:/ IGNORE
If you do it in master.cf for sub
Dnia 12.01.2023 o godz. 15:20:27 Charles Sprickman pisze:
>
> Roundcube webmail has a neat solution - obviously they can't alter the
> header, but they do add their own "received" header with the option of
> "encrypting" it with a fixed key. I'm wondering if that's a "milterable"
> thing - extract
On Thu, Jan 12, 2023 at 09:53:08PM +0100, Jaroslaw Rafa wrote:
> > Roundcube webmail has a neat solution - obviously they can't alter the
> > header, but they do add their own "received" header with the option of
> > "encrypting" it with a fixed key. I'm wondering if that's a "milterable"
> > thin
main.cf:
smtp_header_checks = pcre:/etc/postfix/header_checks_smtp
/etc/postfix/header_checks_smtp:
/^Received:/ IGNORE
/^X-Originating-Ip:/ IGNORE
That's a rather radical "solution". More typically one would just drop
"Received" headers known to be added by the l
On Thu, 12 Jan 2023, post...@ptld.com wrote:
...
As for "X-Originating-Ip:", if you're the one not adding it, why remove it?
And if you are adding it, then why, if only to remove it?
Because the webmail software im using adds it, so I use postfix to strip it
back out.
Isn't it easie
On Thu, Jan 12, 2023 at 04:23:17PM -0500, post...@ptld.com wrote:
> >> /etc/postfix/header_checks_smtp:
> >> /^Received:/ IGNORE
> >> /^X-Originating-Ip:/ IGNORE
>
>
> > That's a rather radical "solution". More typically one would just drop
> > "Received" headers known to
Le 12/01/2023 à 19:45, post...@ptld.com a écrit :
No SPF is OK, but as long as the domain of RFC822 MAIL FROM address
has a SPF, this SPF must pass.
DMARC will pass as long as either SPF or DMARC passes.
DMARC will still pass if SPF fails and DKIM passes.
I think you might be misinterpreting w
Jaroslaw Rafa wrote in
<20230112205215.ga28...@rafa.eu.org>:
|Dnia 12.01.2023 o godz. 13:49:33 post...@ptld.com pisze:
|> My solution...
|>
|> main.cf:
|> smtp_header_checks = pcre:/etc/postfix/header_checks_smtp
|>
|>
|> /etc/postfix/header_checks_smtp:
|> /^Received:/
> It definetely does not work. It only works for smtp not smtpd.
> Also message_drop_headers+=. I now have disabled relay from the
> outside completely and spawn a in-VPN-only-submission
>
> 192.0.2.1:submission inet n - n - - smtpd
> -o syslog_name=vpnsubmission
>
I'm back to the experts for some question. I'm trying to help dig some folks
out of hole. Is there anyway possible to make a decision on where to send mail
based on a friendly from header instead of the envelope from?
I just got done building up a multi-instance postfix set up that was supposed
On Fri, Jan 13, 2023 at 03:22:41AM +, Sean Hennessey wrote:
> I'm back to the experts for some question. I'm trying to help dig some
> folks out of hole. Is there anyway possible to make a decision on
> where to send mail based on a friendly from header instead of the
> envelope from?
NO! Tha
I was using the sender_dependent_default_transport_maps to pick off what I
thought was going to be the interesting from domain. The good news is that this
mail is coming from customer applications. It's not coming from regular user
mail clients. So I can guarantee there is going to be a single f
Emmanuel Fusté skrev den 2023-01-12 17:21:
No. If SPF fail DMARC will fail too.
only for aligned fully
dmarc can pass on spf only aswell as only dkim pass
some versions of dmarc validate arc seal / arc sign
Wietse Venema skrev den 2023-01-12 17:51:
No. If SPF fail DMARC will fail too.
No. If DKIM passes then DMARC should too (ncessary and sufficient).
dmarc specs allow for spf pass only, where there is no dkim signed, eg
if mail is not fully aligned it does not break spf pass only
and spf doe
Emmanuel Fusté skrev den 2023-01-12 18:24:
For to address the forwarding problem, you should add ARC to the
sending and verifying stack, It was designed specifically for that,
but not widely used, it is pretty experimental.
fully implemented in rspamd and now spamassassin 4.0.0
just remember u
Jaroslaw Rafa skrev den 2023-01-12 21:52:
Dnia 12.01.2023 o godz. 13:49:33 post...@ptld.com pisze:
My solution...
main.cf:
smtp_header_checks = pcre:/etc/postfix/header_checks_smtp
/etc/postfix/header_checks_smtp:
/^Received:/ IGNORE
/^X-Originating-Ip:/ IGNORE
If yo
Gerald Galster skrev den 2023-01-13 01:15:
192.0.2.1:submission inet n - n - - smtpd
-o syslog_name=vpnsubmission
-o smtpd_sasl_auth_enable=no
-o
smtpd_relay_restrictions=permit_mynetworks,reject_unauth_destination
-o header_checks=pcre:/etc/postfix/vpn_header_ch
33 matches
Mail list logo
