Re: Postfix advice requested

[Mike Guelfi]

Quoting Viktor Dukhovni :


On Tue, Feb 02, 2021 at 06:12:01PM -0800, david wrote:


At 06:07 PM 2/2/2021, Viktor Dukhovni wrote:
>On Tue, Feb 02, 2021 at 06:46:32PM -0700, Bob Proulx wrote:
>
> > >
> > > a...@d1.tldd1_a
> > > b...@d1.tldd1_b
> > > @d1.tld owner_d1
> > > @d2.tld owner_d2
> >
> > I don't see anything wrong as such with the above.  Seems like it
> > should work.  And for me I have a very similar arrangement here.  So I
> > modified it so that I could test the above case here.  It worked for
> > me here.
>
>Look more closely.  The table as written cannot meet the OP's goals.
>So, no, it does not look like it should work.  It is expected to rewrite
>all the recipients to owner_d1, as reported by the OP.



Why would the line
   @d1.tld owner_d1
apply to ALL recipients?  I want it to apply to recipients at d1.tld,
not d2.dld.  What am I missing?


This is an easy question, that I was hoping someone else would field for
a change.

1. Rewriting via virtual(5) is recursive, with recursion stopping
   either when there's no result, or a key maps to itself.
2. Unqualified RHS values are qualified by appending @$myorigin

Each of these independently makes your table not sufficient for your
needs, in combination it is doubly unsuitable.  The correct syntax is:

@d1.tld owner...@d1.tld
a...@d1.tldd...@d1.tld
b...@d1.tldd...@d1.tld
owner...@d1.tld owner...@d1.tld

@d2.tld owner...@d2.tld
owner...@d2.tld owner...@d2.tld

When using wildcard mappings, always add explicit identity mappings for
RHS values that should not be further expanded.  Always append explicit
domains to RHS values in virtual(5), unless you specifically mean for
them to expand to localport@$myorigin with the suffix defined externally
in main.cf.

Finally, in some cases consider setting "append_mydomain = yes", if you
want to use "localpart@hostname" in tables, without having to specify
an explicit ".$mydomain" suffix after the hostname.  Note that this
is "$mydomain" not "$myorigin" as above.

Good luck.  Lots of folks on this list know the answer to this question,
I guess most of them have not paid attention to this thread (yet).

--
Viktor.


If they're all local accounts, and local domain is d1.tld, should that  
last line be?:

owner...@d2.tld owner...@d1.tld



Regards

--
Mike.

Re: Emails from localhost [OT]

[Mike Guelfi]

Upstream RHEL, and therefore CentOS, don't update version numbers when
they roll security patches.

Latest release though:
2016-10-31 - Jaroslav Škarvada  - 2:2.6.6-8
- Backported support for TLS 1.1, TLS 1.2

Not insanely old...

Quoting "@lbutlr" :


On 03 Jun 2018, at 16:08, Proxy  wrote:

I'm confident that CentOS security team does a good job providing
latest security patches RedHat releases including those related to
Postfix.


Are you under the impression that CentOS is writing security patches
for obsolete and unsupported versions of Postfix?

That is not the case.

There is a big difference between bleeding edge and obsolete, and
you are firmly in the obsolete (as in not support, not patched, not
secure) camp. The last update to 2.6 was over 5 years ago (Feb 2014)
and that is a significantly newer version that you are running (Mar
2010).

--
'They were myths and they were real,' he said loudly. 'Both a wave and a
particle.' --Guards! Guards!

Re: new strangeness with O365 [OT]

[Mike Guelfi]

Quoting Daniele Nicolodi <dani...@grinta.net>:


On 5/17/18 3:59 PM, Mike Guelfi wrote:

Quoting Noel Jones <njo...@megan.vbhcs.org>:

It seems counterproductive to rewrite a plain-text link...  I don't
know it there's a setting in the O365 controls to avoid mangling
plain text, so you may have to live with it.



  -- Noel Jones


The worst of it is, MS are inserting themselves in the transaction so
they get to track which links you click in emails.

There's a good security reason to do so


What MS does is to "check" (whatever that entails) the URL and then
respond to the HTTP client with a redirect. I can envision a very simple
mechanism for which the response served to the MS robot that verify the
URL is different from the one served to other clients.

Can you please elaborate on what are the "good security reasons" for
which that is a good idea and not simply a form of user tracking?

Thanks. Cheers,
Dan


It's at least a reputation service, which means that if they notice it go
bad after they've already sent you the email, they can still block it when
you attempt to click through on their server.

They might be expending some actual effort like sandboxing to inform their
reputation server, or user reporting, etc. But either way it's better from a
service delivery perspective to allow the email before the testing is complete
and hope you click the link afterwards. They have no warranty on the service
anyway so no downside to them.

That said; I have still asked them to turn it off.

I got a 1st level human to acknowledge it's been escalated, but
nothing else so far.

I think this thread is starting to be wildly OT though...

--
Mike.

Re: new strangeness with O365

[Mike Guelfi]

Quoting Noel Jones :


On 5/17/2018 9:40 AM, Fazzina, Angelo wrote:

Hi, wanted to ask if anyone has this issue and how they deal with it ?

 

My work email is on O365 and we just turned ATP and EOP on so emails
with URLS

are being rewritten. That is fine, but my issue is with plain text
emails from

this list.

when they come in i get the rewritten hyper link in the email
instead of the URL

that was posted in the email. You are supposed to hover the mouse
over the URL and then see the link below.

this big mess below is supposed to just be

http:// www. postfix.org/postconf.5.html #reject_unknown_client_hostname

 

O365 seems to work fine when emails are in html and it does it’s
rewriting black magic….

 

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.postfix.org%2Fpostconf.5.html%23reject_unknown_client_hostname=02%7C01%7Cangelo.fazzina%40uconn.edu%7Cc19b58d8248e42ba3c3708d5b85340c2%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C636617590067449013=guRSNY3sghtANvzcdtLMMfUCjXhdVgnNIgoDjRb%2BvQM%3D=0

 

-ANGELO FAZZINA



The ability to hover on a link and see something depends on html
code in the message, so this feature isn't possible in a plain text
mail.

It seems counterproductive to rewrite a plain-text link...  I don't
know it there's a setting in the O365 controls to avoid mangling
plain text, so you may have to live with it.



  -- Noel Jones


The worst of it is, MS are inserting themselves in the transaction so
they get to track which links you click in emails.

There's a good security reason to do so but the problem I have with it
is the opt out isn't a setting, it's a support request to Microsoft to
ask them to please allow you to get email as written. The FAQ attempts
to discourage you from trying, vis:

=
Can I deactivate these security features?
=

To provide the best protection for your account, these features
are on by default
and not designed to be turned off. You can contact our customer
service team via
in-product support to have them deactivate the features on your
behalf, but we do not recommend it.

--
Mike.

Re: Lookup tables

[Mike Guelfi]

postmap is a lookup management tool; doing a query on an IP in a  
subnet isn't going to succeed.


You probably just forgot to enable client_access or reload postfix

What does this return?
# postconf smtpd_client_restrictions

Default is:
smtpd_client_restrictions =

enabled would be:
smtpd_client_restrictions = check_client_access hash:/path/to/client_access

Quoting jack :


Hi,

In the online documentation for access tables
(http://www.postfix.org/access.5.html), it says:

  Subnetworks  are  matched  by  repeatedly  truncating
  the  last ".octet" from the remote IPv4 host address
  string until a  match is found in the access table, or
  until further truncation is not possible.

This is supposedly subject only to the restriction that the table is an
indexed file "such as DB or DBM".

I have the following client_access table:
5.188.9 REJECT WebShield Network trying to hack Dovecot
2018-05-10 - test
5.188.9.1 REJECT WebShield Network trying to hack Dovecot 2018-05-10

I compile the table to create client_access.db:
# postmap client_access

I then try:
# postmap -q 5.188.9.2 client_access
[no output]

# postmap -q 5.188.9.1 client_access
REJECT WebShield Network trying to hack Dovecot 2018-05-10

The behaviour of postmap seems to be at odds with the documentation;
specfically, it does not seem to be possible to match an address against
an address-prefix in the table. Am I misunderstanding the docs, or do
they need fixing?

I haven't tried any of the other indexed lookup types; is there some
other table type that works properly? Do I need to test them all to see
if they comply with the docs?

Thanks,
--
Jack.

Re: Delays in writing to INBOX

[Mike Guelfi]

Sounds like GFS2 operating normally.

Do you have any metrics on for the performance of the SAN during these events?

Quoting Durga Prasad Malyala :


Hello all,
I am seeing consistent delays in writing to disk (my System redhat 7.2
 using GFS2 file system cluster)

May  4 10:03:34 mail1 postfix/lmtp[11662]: E4EB75048C19:
to=, relay=mail.xyz.com[private/dovecot-lmtp], delay=50,
delays=0.02/0/0/50, dsn=2.0.0, status=sent (250 2.0.0 
IIt4Ejji61o3LgAAuUaIWw Saved)

during major bursts of receiving mailq delays goes upto 600+ also.

GFS2 writing is OK. Not as great as XFS but OK. Disk bottleneck is
ruled out as it is a 3PAR SAN with 16 Gbps FC.

ocassionally we get  "timed out while sending end of data -- message
may be sent more than once)" message also and Message goes to deferred
queue.

Thanks
DP

Re: Recording of DANE talk at ICANN61

[Mike Guelfi]

The m3u contains a link to: http://audio.icann.org/meetings/sju61/sju61-OPEN-2018-03-14-T1732-208bc-zYhNI147Nrs4gtkXUVItrT4uukdYi3nR-en-02.mp3Which does work...On 19 Mar. 2018 19:50, Dominic Raferd  wrote:On 17 March 2018 at 19:42, Viktor Dukhovni  wrote:
[ Also posted to dane-us...@sys4.de, please pardon the duplication if
  you're reading both lists.  I'm planning to also post to exim-users
  and d...@ietf.org ]

I gave a talk about DANE for SMTP at the ICANN61 conference last week.
Audio and slides are available, but not a synchronized recording so if
you want to follow along you'll need to figure out the slide transitions
from the context of the audio.  I was promised 45 minutes, had too much
material even for that, but only got 35 minutes, and yet managed to get
to most of the key points.  I hope and think that the pace was not too
fast to get the points across.

My segment starts at 16 minutes into the recording and ends 51 minutes
into the recording:

  http://audio.icann.org/meetings/sju61/sju61-OPEN-2018-03-14-T1732-208bc-zYhNI147Nrs4gtkXUVItrT4uukdYi3nR-en.m3u

The slides are at:

  https://static.ptbl.co/static/attachments/169319/1520904692.pdf

The slides have additional material in the Appendix section.  Please
take the key rotation advice in the slides seriously and apply it to
improve your own practices.  May your TLSA records never fail to
validate, even briefly...

--
        Viktor.​There may be a problem with the audio link - I can't get it to play.​

Re: Postfix is slow accepting incoming mails

[Mike Guelfi]

postconf -nWould be more useful...

Re: Microsoft silently discarding emails after recepit

[Mike Guelfi]

Our alternative was always to just set relays for "poorly behaved" domains to go through the ISP email servers. It was slower but more reliable since the ISP had an artificially inflated reputation and more time to complain when it's email was.blocked.

Re: problem with protection.outlook.com released spam getting bounced

[Mike Guelfi]

Assuming the header check works, I'd run that on a different instance  
of postfix and route the specific outside servers to that instance via  
the firewall...


Quoting John Stoffel :


Well, I've confirmed that EOP (protection.outloko.com, our external
Spam filter provider) is adding in the "Delivered-To:" head when
emails that have been quarrantined are released to be delivered in to
us.

I'm amazed others haven't seen this problem yet, but maybe we're
strange.  In any case, now I need to figure out a way to fix this.

Would it be enough to simply remove the header if it arrives from
them?  I know it's a bad idea... but my customers are complaining
about this.

So a simple header_check like this might be what I want:

/^Delivered-To: (.*$)/ REPLACE EOP-Delivered-To: "$1"

But I only want this replamcent to happen for email that comes from a
specific set of outside servers.  I think I might have to run my own
milter here to do this.   I really can't depend on the headers not
being forged somehow, but I can depend on the host which connects to
me being who it says.

To a degree.

Am I making sense?
John

Re: how to remove string "[MASSMAIL]" from the subject ?

[Mike Guelfi]

Surely that's going to need to be:
/^Subject:(.*)\[MASSMAIL\](.*)/ REPLACE Subject: $1$2

Quoting Ralf Hildebrandt :


* Zalezny Niezalezny :

As I see here header_checks can do it. There is only one problem. This rule
searching for a subject with string [MASSMAIL] and replacing complete
subject line with word "test".

/^Subject:.*[MASSMAIL].*/ REPLACE Subject: test


/^Subject:(.*)[MASSMAIL](.*)/ REPLACE Subject: $1$2

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: How to setup a no-answer email properly

[Mike Guelfi]

If people want to use a non RFC compliant verification system, then  
they're going to have problems with false positives on their spam  
filter.


The operative word being: they.

Your customer needs to get their email vendor to whitelist your trac  
instance. You don't need to do anything


--
Mike.

Quoting Dirk Stöcker :


On Sat, 18 Mar 2017, Richard Damon wrote:


- On your side, don't reject RCPT TO for the no-reply address.

- On your side, add a telepathic policy service that can distinguish
between RCPT TO to verify an address, and RCPT to deliver mail.

smtpd_recipient_restrictions =
 
 reject_unauth_destination
 check_policy_service unix:/some/where/telepathic-service
 check_recipient_access inline:{
 { t...@email.tld = reject this address does not receive email }
 }

 Wietse

Couldn't you do something where you accept at the RCPT TO, and then  
reject at End of Data having it just reject everything as spam?


http://www.postfix.org/SMTPD_PROXY_README.html

When its even possible to check spam without generating a bounce  
message, why do I need telepathy to reject a mail for a known  
situation in a later stage of mail delivery?


It is a bit of overkill to write a filter for that. I hoped there  
would be an easier way.


Could it work to "Configure the Postfix SMTP pass-through proxy  
feature" with the after filter SMTP server being directly the target  
(i.e. omitting the filter) and putting the recipient reject on this  
one instead of the initial connect?


Ciao
--
http://www.dstoecker.eu/ (PGP key available)






Cheers,

--
Mike.