Re: ADVICE: Best Practice - Usernames with Domain components

[mj]

Hi,

I have read your mail, and we're using a setup similar to yours (samba, 
postfix, debian) and we're using 'regular' usernames, without the domain 
prefix.


Sometimes, but only in windows, we specify a domain name to make clear 
to windows that we mean the DOMAIN account username, and not a local 
account, or DOMAINB\username.


But in common practise, we never login anywhere with DOMAIN\username

And we also never have the issues you are describing, and no need fotr 
mappings of any kind.


Are you *sure* you need your usernames in that format?

MJ


On 26/05/2020 13:50, Nick Piggott wrote:

Hello,

Here's my setup:
* Ubuntu 18.04 LTS
* Postfix 3.3.0
* Mailutils 3.4
* Samba 4.7.6
* Active Directory (provided by Samba)

My usernames are of the format:
* DOMAIN\username

I can separately maintain a list of mappings between DOMAIN\username
and username.

Here are the problems I'm looking to solve appropriately:
* mail - sends the origination user as "DOMAIN\username", which
postfix provides onto the destination mail exchanger, which rejects it
as being an incorrect format
* postfix - is configured with:
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
which flattens the return address to "domain\username", and creates a
mailbox in /var/mail as "domain\username". When the user types "mail"
to read their email, it opens "DOMAIN\username", so they never see
their newly received messages.

Things I have tried:
* Using
sender_canonical_maps = hash:\etc\postfix\sender_canonical
to change a specific DOMAIN\username to username. It didn't work,
although I could see it parsing sender_canonical.db when sending. The
exact line was
DOMAIN\\username : username
Postfix still provided "DOMAIN\username" as the originator to the
destination mail exchanger.
* Using
recipient_canonical_maps = hash:\etc\postfix\recipient_canonical
to convert a specific username back to DOMAIN\username. That failed
because the output is still casefolded to domain\username before
writing to the mailbox file.

Questions:
* Am I trying the right approach to rewriting the originating email
address from DOMAIN\username to username? What am I potentially
missing to get it working?
* As postfix will always fold the return address to lowercase (because
of the local_recipient_maps filter), should I just softlink together
the mailbox files DOMAIN\username and domain\username in /var/mail, or
is there a solution I can put into postfix to revert back to
DOMAIN\username before outputting to the mail file?

Thanks in advance,

Re: Preferred/maintained greylisting options?

[Doug Hardie]

> On 25 May 2020, at 12:00, Chris Wedgwood  wrote:
> 
>> Greylisting has become pretty much useless.  When I disabled it a
>> couple years ago, the spam levers did not increase by any measurable
>> amount.  We now use just 3 RBLs and that seems to be a relatively
>> acceptable level of spam.
> 
> Checking for %ge of messages that "return after defer" I see:
> 
>WeekOf  PctReturned
>--  ---
>2020-04-30  22.1
>2020-05-07  26.5
>2020-05-14  21.2
>2020-05-21  26.5

I would guess that our users were hit by spammers with more resources ;-)  I 
would have kept greylisting if we had seen numbers like that.

-- Doug

Re: Preferred/maintained greylisting options?

[Chris Wedgwood]

> Contrary to someone else's experience related in this thread, I
> still see a significant amount of spam that greylisting blocks, and
> extremely few spammers retry and get through.

I concurn, as reported, I curently see greylisting reduce spam by a
factor of 4.

> I have only had one known case (i.e. someone said they were
> expecting an email that they didn't receive) in a very long time
> where a legitimate email was greylisted and the sending server did
> not retry, and that was recently from an outlook365 server.

Aliexpress is one perplexing offender I've had to deal with.

The send badly formed messages, retry aggressively for a few seconds
then never again so messages get lost.

I've not been able to reach anyone there.

SNI problem

[Ján Máté]

Hi Postfix users,

I have a problem with the new tls_server_sni_maps configuration option - it 
seems that Postfix (3.4.10 debian-buster) is unable to load the key+cert+chain 
combination using this option. The error is "SNI data for smtp.myserver.eu 
 does not match next certificate" even if I am 100% 
sure that the key+cert+chain is OK, because I use the same key+cert+chain 
(loaded from same files) for the smtpd_tls_chain_files (and there it works).

Related config files:

/etc/postfix/main.cf:
tls_server_sni_maps = hash:/etc/postfix/table_hash-tls_server_sni_maps
smtpd_tls_chain_files =
/etc/letsencrypt/live/eu.server.smtp/privkey.pem
/etc/letsencrypt/live/eu.server.smtp/fullchain.pem

/etc/postfix/table_hash-tls_server_sni_maps (indexed using: postmap 
-F hash:/etc/postfix/table_hash-tls_server_sni_maps):
smtp.myserver.eu  
/etc/letsencrypt/live/eu.myserver.smtp/privkey.pem 
/etc/letsencrypt/live/eu.myserver.smtp/fullchain.pem
smtp.myserver2.eu  
/etc/letsencrypt/live/eu.myserver2.smtp/privkey.pem 
/etc/letsencrypt/live/eu.myserver2.smtp/fullchain.pem


Key+cert+chain hash info (the fullchain.pem file contains the cert.pem + 
chain.pem):
=== privkey.pem
ee key hash
(stdin)= b6dae1eecaa9a2b366b2acddf2ea2cfcec4fe8132ad2e8147be487b0ef241fc3
ee cert pubkey hash
(stdin)= -NONE-
ee chain names

=== cert.pem
ee key hash
(stdin)= -NONE-
ee cert pubkey hash
(stdin)= b6dae1eecaa9a2b366b2acddf2ea2cfcec4fe8132ad2e8147be487b0ef241fc3
ee chain names
subject=CN = smtp.myserver.eu 
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

=== chain.pem
ee key hash
(stdin)= -NONE-
ee cert pubkey hash
(stdin)= 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
ee chain names
subject=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
issuer=O = Digital Signature Trust Co., CN = DST Root CA X3



Info related to my testing:

Connection to Postfix from a remote server (client) using the correct 
"servername" in the SNI:

root@otherserver:~# openssl s_client -servername smtp.myserver.eu 
 -starttls smtp -connect smtp.myserver.eu:25 

CONNECTED(0003)
140179153458304:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert 
internal error:../ssl/record/rec_layer_s3.c:1544:SSL alert number 80
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 335 bytes and written 726 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Postfix server logs (server):

May 26 22:38:58 myserver postfix/smtpd[72379]: maps_file_find: 
tls_server_sni_maps: 
hash:/etc/postfix/table_hash-tls_server_sni_maps(0,lock|fold_fix|src_rhs_is_file):
 smtp.myserver.eu  = 
LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUpRd0lCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQ1Mwd2dna3BBZ0VBQW9J...
May 26 22:38:58 myserver postfix/smtpd[72379]: warning: key at index 1 in SNI 
data for smtp.myserver.eu  does not match next 
certificate
May 26 22:38:58 myserver postfix/smtpd[72379]: warning: TLS library problem: 
error:1426D121:SSL routines:ssl_set_cert_and_key:not replacing 
certificate:../ssl/ssl_rsa.c:1107:
May 26 22:38:58 myserver postfix/smtpd[72379]: warning: error loading private 
keys and certificates from: SNI data for smtp.myserver.eu 
: aborting TLS handshake



Connection to Postfix from a remote server (client) without SNI servername (or 
SNI name not present in the tls_server_sni_maps):

root@otherserver:~# openssl s_client -noservername -starttls smtp -connect 
smtp.myserver.eu:25 
CONNECTED(0003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = smtp.myserver.eu 
verify return:1
---
Certificate chain
 0 s:CN = smtp.myserver.eu 
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-BEGIN CERTIFICATE-
...
...
...
-END CERTIFICATE-
subject=CN = smtp.myserver.eu 

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 4013 bytes and written 744 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No 

Re: Postfix -> Whatapp

[Phil Stracchino]

On 2020-05-26 13:42, Jos Chrispijn wrote:
> Is there a way of Postfix sending a Whatsapp message to a user when
> there came in email for her/him?
> 
> Thanks, Jos

No.  That is utterly and totally not Postfix's, or any MTA's, job.  Period.

If you wanted to get a WhatsApp notification when you receive new mail,
you'd need to find a mail *client* that has some kind of WhatsApp
notification plugin.  (Good luck with that.)


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958

Re: Postfix -> Whatapp

[Jos Chrispijn]

On 26-5-20 21:18, vi...@vheuser.com wrote:


I hate to see folks on a user list throw down at a question.
More helpful than "No way, utterly" is "Here's how to".


Thanks. I just asked if this is possible. Sorry if I offended someone.


The question was how to initiate a script upon receipt of an email.
Here's a suggestion:
https://unix.stackexchange.com/questions/178396/run-script-on-receipt-of-email


Thanks for your suggestion, will follow up that one.
Jos

-- With both feet on the ground you can't make any step forward

Re: Postfix -> Whatapp

[Jaroslaw Rafa]

Dnia 26.05.2020 o godz. 13:06:54 Bill Gee pisze:
> Almost completely irrelevant, but still an interesting (and true!) story
> ...  About 30 years ago I started a job at an insurance company.  At that
> time less than half the company had PCs.  Most had 3270 green screen
> terminals.  The corporate email was SYSM running on a System 370
> mainframe.  Someone had cleverly arranged things so that whenever you got
> an email, it would send you a voice mail.
> 
> Fast-forward 25 years:  After several acquisitions and many changes of
> email, the company is now running on Exchange.  Someone very clever rigged
> up a system so that whenever you got a voice mail, it sent you an email.
> 
> How things go around!

Well, that reminds me of a thought that came to me a few years ago when I
looked at my desk. There is a computer, a telephone and some "box" to which
these two are connected. About 20 years ago there was also a computer, a
telephone, and some "box" to which these two were connected.

But that "box" 20 years ago was a dial-up modem. My computer was accessing
the Internet via that modem, connected to a telephone line.

Now I don't have a telephone line anymore. An Ethernet cable is coming out
of my wall, connected to my home router which has an integrated VoIP
gateway. A telephone is connected to the router, and I make phone calls over
the Internet... :)
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Postfix -> Whatapp

[Phil Stracchino]

On 2020-05-26 15:18, vi...@vheuser.com wrote:
> More helpful than "No way, utterly" is "Here's how to".
> The question was how to initiate a script upon receipt of an email.
> Here's a suggestion:
> https://unix.stackexchange.com/questions/178396/run-script-on-receipt-of-email

I note that the stackexchange link talks about doing this at the
client/mailbox level, which is completely valid.  Getting WhatsApp
notification BUILT INTO a client is unlikely, but there might be
plugins, and there's certainly ways to script it externally.

Nevertheless, I reiterate that it is not any mail *transfer* agent's
job.  Certainly the goal of notification-on-email-receipt can be done.
That's not even in question.  But Postfix is not the place to do it.


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958

Re: Postfix -> Whatapp

[Jos Chrispijn]

On 26-5-20 21:24, J Doe wrote:

You may want to investigate doing this at the MDA.  If you run Dovecot 
in conjunction with Postfix, you could write a Sieve script that calls a 
shell script that then sends the notification to whatever third-party 
service you would like.


As a side-note - there actually is a Sieve RFC that covers notifications 
via XMPP / Jabber, but that isn't available in Dovecot at the moment.


Thanks, I will check this solution is also workable for me.
Best, Jos


-- With both feet on the ground you can't make any step forward

Re: Postfix -> Whatapp

[vi...@vheuser.com]

On 2020/05/26 14:06 PM, Bill Gee wrote:


Almost completely irrelevant, but still an interesting (and true!) story ... About 30 
years ago I started a job at an insurance company. At that time less than half the 
company had PCs. Most had 3270 green screen terminals. The corporate email was SYSM 
running on a System 370 mainframe. Someone had cleverly arranged things so that whenever 
you got an email, it would send you a voice mail.


Fast-forward 25 years: After several acquisitions and many changes of email, the company 
is now running on Exchange. Someone very clever rigged up a system so that whenever you 
got a voice mail, it sent you an email.


How things go around! --

Bill Gee

On Tuesday, May 26, 2020 12:52:13 PM CDT Phil Stracchino wrote:

> On 2020-05-26 13:42, Jos Chrispijn wrote:

> > Is there a way of Postfix sending a Whatsapp message to a user when

> > there came in email for her/him?

> >

> > Thanks, Jos

>

> No. That is utterly and totally not Postfix's, or any MTA's, job. Period.

>

> If you wanted to get a WhatsApp notification when you receive new mail,

> you'd need to find a mail *client* that has some kind of WhatsApp

> notification plugin. (Good luck with that.)

>

>

>


Good story, Bill.  Did some of that on a DEC10 myself.
 Too bad not everyone shares your conviviality.
I hate to see folks on a user list throw down at a question.
More helpful than "No way, utterly" is "Here's how to".
The question was how to initiate a script upon receipt of an email.
Here's a suggestion:
https://unix.stackexchange.com/questions/178396/run-script-on-receipt-of-email

Re: Postfix -> Whatapp

[J Doe]

On 2020-05-26 1:52 p.m., Phil Stracchino wrote:

On 2020-05-26 13:42, Jos Chrispijn wrote:

Is there a way of Postfix sending a Whatsapp message to a user when
there came in email for her/him?

Thanks, Jos

No.  That is utterly and totally not Postfix's, or any MTA's, job.  Period.

If you wanted to get a WhatsApp notification when you receive new mail,
you'd need to find a mail *client* that has some kind of WhatsApp
notification plugin.  (Good luck with that.)


Hi Jos,

You may want to investigate doing this at the MDA.  If you run Dovecot 
in conjunction with Postfix, you could write a Sieve script that calls a 
shell script that then sends the notification to whatever third-party 
service you would like.


As a side-note - there actually is a Sieve RFC that covers notifications 
via XMPP / Jabber, but that isn't available in Dovecot at the moment.


- J

Re: Preferred/maintained greylisting options?

[Marvin Renich]

* Laura Smith  [200524 16:00]:
> > I’ve been sort of opposed to greylisting in the past due to a
> > userbase that’s sensitive to delays, but… the spam is worse.
> 
> IMHO Greylisting is rather pointless. Its a blunt tool, and not only
> that it does that unforgivable thing of annoying genuine people.

I agree that greylisting, as most documentation, blogs, etc, describe
how to configure it, has always been a bad idea, primarily because it
delays most or all mail that is not whitelisted.

However, when I first set up greylisting on my family email server (it
was exim way back then, but has long been postfix), I set it up so that
all incoming mail was sent through spamassassin _during_ SMTP, prior to
accept or reject.  Mail with a high enough spam score was rejected
outright.  I then used greylisting _only_ for email whose spamassassin
score was considered spam, but not high enough to reject outright.

This setup virtually eliminates false positives from spamassassin, and
avoids delaying legitimate email except for the few that would have been
rejected falsely.

Contrary to someone else's experience related in this thread, I still
see a significant amount of spam that greylisting blocks, and extremely
few spammers retry and get through.

I have only had one known case (i.e. someone said they were expecting an
email that they didn't receive) in a very long time where a legitimate
email was greylisted and the sending server did not retry, and that was
recently from an outlook365 server.  Ironically, someone was following
Microsoft's instructions to have an IP address removed from outlook365's
internal RBL, and the message sent by Microsoft failed several of
spamassassin's default tests (way to go, Microsoft!) and their server
never retried (I watched the logs and they did not retry from a
different IP address).  What a well-run mail system,
Microsoft.

...Marvin

Re: Postfix -> Whatapp

[Jos Chrispijn]

On 26-5-20 21:59, Wietse Venema wrote:


Sure. Use recipient_bcc_maps to add an extra recipient to their
email messages.That extra recipient goes through transport_maps to a
pipe daemon that invokes a command that sends a whatsapp message.


Great suggestion, thanks for that!
Best, Jos

-- With both feet on the ground you can't make any step forward

Re: Postfix -> Whatapp

[Wietse Venema]

Jos Chrispijn:
> Is there a way of Postfix sending a Whatsapp message to a user when 
> there came in email for her/him?

Sure. Use recipient_bcc_maps to add an extra recipient to their
email messages.That extra recipient goes through transport_maps to a
pipe daemon that invokes a command that sends a whatsapp message.

Wietse

Re: Postfix -> Whatapp

[Bill Gee]

Almost completely irrelevant, but still an interesting (and true!) story ...  
About 30 years ago I started a job at an insurance company.  At that time less 
than half the company had PCs.  Most had 3270 green screen terminals.  The 
corporate email was SYSM running on a System 370 mainframe.  Someone had 
cleverly arranged things so that whenever you got an email, it would send you a 
voice mail.

Fast-forward 25 years:  After several acquisitions and many changes of email, 
the company is now running on Exchange.  Someone very clever rigged up a system 
so that whenever you got a voice mail, it sent you an email.

How things go around!

-- 
Bill Gee



On Tuesday, May 26, 2020 12:52:13 PM CDT Phil Stracchino wrote:
> On 2020-05-26 13:42, Jos Chrispijn wrote:
> > Is there a way of Postfix sending a Whatsapp message to a user when
> > there came in email for her/him?
> > 
> > Thanks, Jos
> 
> No.  That is utterly and totally not Postfix's, or any MTA's, job.  Period.
> 
> If you wanted to get a WhatsApp notification when you receive new mail,
> you'd need to find a mail *client* that has some kind of WhatsApp
> notification plugin.  (Good luck with that.)
> 
> 
> 

Postfix -> Whatapp

[Jos Chrispijn]

Is there a way of Postfix sending a Whatsapp message to a user when 
there came in email for her/him?


Thanks, Jos

-- With both feet on the ground you can't make any step forward 

ADVICE: Best Practice - Usernames with Domain components

[Nick Piggott]

Hello,

Here's my setup:
* Ubuntu 18.04 LTS
* Postfix 3.3.0
* Mailutils 3.4
* Samba 4.7.6
* Active Directory (provided by Samba)

My usernames are of the format:
* DOMAIN\username

I can separately maintain a list of mappings between DOMAIN\username
and username.

Here are the problems I'm looking to solve appropriately:
* mail - sends the origination user as "DOMAIN\username", which
postfix provides onto the destination mail exchanger, which rejects it
as being an incorrect format
* postfix - is configured with:
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
which flattens the return address to "domain\username", and creates a
mailbox in /var/mail as "domain\username". When the user types "mail"
to read their email, it opens "DOMAIN\username", so they never see
their newly received messages.

Things I have tried:
* Using
sender_canonical_maps = hash:\etc\postfix\sender_canonical
to change a specific DOMAIN\username to username. It didn't work,
although I could see it parsing sender_canonical.db when sending. The
exact line was
DOMAIN\\username : username
Postfix still provided "DOMAIN\username" as the originator to the
destination mail exchanger.
* Using
recipient_canonical_maps = hash:\etc\postfix\recipient_canonical
to convert a specific username back to DOMAIN\username. That failed
because the output is still casefolded to domain\username before
writing to the mailbox file.

Questions:
* Am I trying the right approach to rewriting the originating email
address from DOMAIN\username to username? What am I potentially
missing to get it working?
* As postfix will always fold the return address to lowercase (because
of the local_recipient_maps filter), should I just softlink together
the mailbox files DOMAIN\username and domain\username in /var/mail, or
is there a solution I can put into postfix to revert back to
DOMAIN\username before outputting to the mail file?

Thanks in advance,

-- 
Nick