Today is a good day to DANE!

[raf]

Hi,

If you'd like to point DANE at your postfix server,
today might be a good day to look into it. If not,
please ignore the rest of this post. And apologies if
this is all old news to you.

If you use Debian stable, and ISC Bind, it has just
become really really easy to implement DNSSEC for your
domain(s).

Debian-11 has just been released, and it has
bind-9.16.15 which has brilliant support for automatic
DNSSEC signing, including key rollovers. But Hardware
Security Module (HSM) users still need to keep doing
what they're doing.

If you don't mind having a key that lasts "forever",
you only need one(!) extra line in Bind's zone config,
and one(!) manual interaction with your domain
registrar. And you can just initiate a manual key
rollover if it ever get compromised, or whenever it
suits you.

Regular key rollovers only require a few more lines of
config and (e.g.) annual interactions with your domain
registrar (until TLDs implement automatic goodness).

BUT BE WARNED: Do not put your dnssec-policy directive
in the options {} stanza, to apply to all zones, or it
will immediately go horribly wrong (i.e. crash crash
crash panic cleanup rollback large whisky).
Put dnssec-policy directives in zone {} stanzas only,
and it behaves beautifully.

I've started the process and am waiting for Bind to
indicate that the time is right to inform my registrar.

Once DNSSEC is sorted, DANE should be relatively easy. :-)
(unless you use LetsEncrypt)

Here's some further reading for those who are interested:

  https://bind9.readthedocs.io/en/v9_16_15/dnssec-guide.html
  https://tools.ietf.org/html/rfc7671 (DANE) (Proposed Standard)
  https://weberblog.net/how-to-use-danetlsa/
  https://www.huque.com/bin/gen_tlsa
  https://blog.tyk.nu/blog/generating-tlsa-records-with-openssl/
  http://www.postfix.org/postfix-tls.1.html (See output-server-tlsa)
  https://imrryr.org/~viktor/ICANN61-viktor.pdf
  https://imrryr.org/~viktor/ICANN61-viktor.mp3
  
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
  
https://www.internetsociety.org/blog/2016/01/lets-encrypt-certificates-for-mail-servers-and-dane-part-1-of-2/
  
https://www.internetsociety.org/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/
  The above uses letsencrypt-auto rather than certbot
  but the ideas are important if you use LetsEncrypt.
  https://blog.hansenpartnership.com/using-letsencrypt-certificates-with-dane/

LetsEncrypt (or rather certbot) doesn't play super-well
with DANE (for the way I want to do it - TLSA 3 1 1
records only, not TLSA 2 1 1 records). There are
several old threads on community.letsencrypt.org about
DANE but I didn't find very clear actual instructions,
but it's still very useful to read. The last URL above
(I think) gives the best approach for my preference.

Because I had an existing LetsEncrypt certificate via
certbot, I wanted to keep using it, so (I think) I've
told it to keep the same private key every time it
renews (--reuse-key / reuse_key = True). But that's
only OK if you are happy to keep the same private key
forever, which would be bad. I don't know how to
combine --reuse-key with annual key rollovers that are
certbot-compatible. I'm not actually sure it's possible.

I only want to use TLSA 3 1 1 records (because 2 1 1
ones seem too fiddly for me), so I think that I really
need to change to creating my own private keys outside
certbot, and using certbot's --csr option to get
LetsEncrypt to certify them. That way, I can have
multiple private keys in existence at the same time,
and create TLSA records for each of them (i.e. current
and next), and rollover to the next one on my own
schedule.

But it means that certbot can't automate the renewal of
the certificates. And I need to cron that separately. I
need to learn more about certbot.

If anyone has recent experience with certbot and TLSA 3
1 1 records, I'd appreciate any advice. Maybe I'll ask
on community.letsencrypt.org.

Without LetsEncrypt, this would be so much easier, but
I want certbot and DANE to play nice together. I'm not
giving up yet. :-)

It's tempting to think it would be OK to use
LetsEncrypt/certbot for the web, and handle mail
separately, but the TLS certificate used for mail
submission ports 465/587 should be CA-approved to keep
(non-DANE aware) mail submission agents happy, and
postfix uses the same certificate for all ports
(25/465/587). So I want using certbot for DANE to be
easy.

cheers,
raf

P.S. Apologies if this is too off-topic, but I thought
it might be useful to the debian+stable+bind+dnssec+dane
loving subset of the postfix audience.

Re: Today is a good day to DANE!

[Viktor Dukhovni]

On Tue, Aug 17, 2021 at 06:12:04PM +1000, raf wrote:

> If you use Debian stable, and ISC Bind, it has just
> become really really easy to implement DNSSEC for your
> domain(s).

Indeed, BIND 9.16 makes it dramatically easier to sign your DNS zone and
keep it signed reliably.  It automates ZSK rollover, and simplifies KSK
rollover, including algorithm changes...

By all means please consider deploying DNSSEC for your zone.  As with
any technology, don't just fire and forget, implement monitoring.  One
tool I very much recommend is "ldns-verify-zone".  It can check all
zone signatures, and whether any will expire too soon, ...

> Once DNSSEC is sorted, DANE should be relatively easy. :-) (unless you
> use LetsEncrypt)

There are two parts to implementing DANE, server and client.

- On the client side you just need a local (loopback) validating
  resolver, your own zone need not be signed.  With that in place
  enabling DANE in the Postfix SMTP client is easy.

  In http://www.postfix.org/TLS_README.html#client_tls_dane I
  explained how to enable DANE selectively.  That was some time
  back.  We should probably change the documentation to recommend:

  main.cf:
  # Make sure /etc/resolv.conf lists only looopback nameservers,
  # if you list remote nameservers, their "AD" bit is easily
  # spoofed via active MiTM attacks.
  #
  smtp_dns_support_level = dnssec
  smtp_tls_security_level = dane

- On the server side, no configuration changes in Postfix are
  required beyond deploying TLS (with a certificate that
  consistently matches the published DANE TLSA records).

  It is however critical to implement monitoring and a robust
  key/cert rollover process from the get go, *before* you publish
  your first TLSA RRset.  Take care of those first, and only
  then publish TLSA records.

  See https://stats.dnssec-tools.org/ and the resources links at:
  

> LetsEncrypt (or rather certbot) doesn't play super-well with DANE (for
> the way I want to do it - TLSA 3 1 1 records only, not TLSA 2 1 1
> records). There are several old threads on community.letsencrypt.org
> about DANE but I didn't find very clear actual instructions, but it's
> still very useful to read. The last URL above (I think) gives the best
> approach for my preference.

The key is to keep the key fixed unless and until you have TLSA records
in place for the next planned key.  At that point, get Let's Encrypt to
renew your certificate with that key.

The main difficulty is that Let's Encrypt makes it easy to keep the key
fixed, or to generate a fresh random key (rather than a pre-configured
key as needed here).  I need to polish and release my code that provides
the missing functionality, and delays the key rollover until after the
TLSA records have been in place for a sufficiently long time (multiple
TTLs).

Let's Encrypt does have a "--csr" option that sophisticated users can
use to implement the above, if you've already figured out how to do
that, great.  Otherwise, just stick to a fixed key.

> Because I had an existing LetsEncrypt certificate via certbot, I
> wanted to keep using it, so (I think) I've told it to keep the same
> private key every time it renews (--reuse-key / reuse_key = True). But
> that's only OK if you are happy to keep the same private key forever,
> which would be bad. I don't know how to combine --reuse-key with
> annual key rollovers that are certbot-compatible. I'm not actually
> sure it's possible.

It is, but stay tuned...

> I only want to use TLSA 3 1 1 records (because 2 1 1 ones seem too
> fiddly for me),

Also fragile, because Let's Encrypt switches to a new issuer CA from
time to time, and some users don't pay attention to the announcements:

http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html

> so I think that I really need to change to creating my own private
> keys outside certbot, and using certbot's --csr option to get
> LetsEncrypt to certify them. That way, I can have multiple private
> keys in existence at the same time, and create TLSA records for each
> of them (i.e. current and next), and rollover to the next one on my
> own schedule.

Correct.

> If anyone has recent experience with certbot and TLSA 3
> 1 1 records, I'd appreciate any advice. Maybe I'll ask
> on community.letsencrypt.org.

I have code that solves the problem, but not yet ready for
release.  It'll be called "danebot"...

> It's tempting to think it would be OK to use
> LetsEncrypt/certbot for the web, and handle mail
> separately, but the TLS certificate used for mail
> submission ports 465/587 should be CA-approved to keep
> (non-DANE aware) mail submission agents happy, and
> postfix uses the same certificate for all ports
> (25/465/587).

This is not the case.  You can have a different certificate chain for
465/587 by making simple master.cf overrides either for those servic

Google spam...

[SH Development]

We have been getting inundated by spam from Google (gmail).

I know that if our server gets reported for even a few spammy messages, Google 
won’t hesitate to block our server.

Short of blocking Google on our server, is there some place to report spam we 
have received from the Google platform?

SH

Re: Google spam...

[Viktor Dukhovni]

> On 17 Aug 2021, at 5:13 pm, SH Development  
> wrote:
> 
> We have been getting inundated by spam from Google (gmail).
> 
> I know that if our server gets reported for even a few spammy messages, 
> Google won’t hesitate to block our server.
> 
> Short of blocking Google on our server, is there some place to report spam we 
> have received from the Google platform?

Yes, but I doubt it would have any meaningful effect. :-(

You can (with much manual effort) fill in Google's abuse report form:

https://support.google.com/mail/contact/abuse

or (easier, but no idea whether this is effective), use an IMAP client
to move the message into the INBOX of a Gmail account, and then report
it as spam.

Unless you have friends in high places at Gmail, or manage to get law
enforcement interested, you're unlikely to get much feedback.

-- 
Viktor.

Re: Google spam...

[Dan Mahoney]

> On Aug 17, 2021, at 2:13 PM, SH Development  
> wrote:
> 
> We have been getting inundated by spam from Google (gmail).
> 
> I know that if our server gets reported for even a few spammy messages, 
> Google won’t hesitate to block our server.
> 
> Short of blocking Google on our server, is there some place to report spam we 
> have received from the Google platform?

Short answer: No.  I also get added regularly to UAE-based google groups job 
boards that inundate me with resumes, and there's no way to report these.  

(When I'm feeling kind, I offer criticism and well-wishes)

Same issue with outlook.com, for what it's worth.  I get spammed by 
dmarc-passing sharepoint notifications from sexy girls, I am on office.com's 
feedback loop but occasionally get blocklisted for no reason.

Neither answers abuse@, there's no way to get a human.

It's incredibly frustrating.

-Dan

Re: Google spam...

[Benny Pedersen]

On 2021-08-17 23:35, Viktor Dukhovni wrote:


Yes, but I doubt it would have any meaningful effect. :-(


hope google can do better with dkim reports, not accepting reports with 
brokken dkim signs from google :/



You can (with much manual effort) fill in Google's abuse report form:

https://support.google.com/mail/contact/abuse


bookmarked here


or (easier, but no idea whether this is effective), use an IMAP client
to move the message into the INBOX of a Gmail account, and then report
it as spam.


yes this is hopefully best efforts there, but imho the learned data is 
so only usefull for that imap user, i dont think date from one single 
user will make it default into all gmail users



Unless you have friends in high places at Gmail, or manage to get law
enforcement interested, you're unlikely to get much feedback.


i only know one :=)

Re: Google spam...

[Vince Heuser]

What's the matter with ab...@google.com  and at spamcop.net?




On 2021/08/17 17:35 PM, Viktor Dukhovni wrote:

On 17 Aug 2021, at 5:13 pm, SH Development  wrote:

We have been getting inundated by spam from Google (gmail).

I know that if our server gets reported for even a few spammy messages, Google 
won’t hesitate to block our server.

Short of blocking Google on our server, is there some place to report spam we 
have received from the Google platform?

Yes, but I doubt it would have any meaningful effect. :-(

You can (with much manual effort) fill in Google's abuse report form:

https://support.google.com/mail/contact/abuse

or (easier, but no idea whether this is effective), use an IMAP client
to move the message into the INBOX of a Gmail account, and then report
it as spam.

Unless you have friends in high places at Gmail, or manage to get law
enforcement interested, you're unlikely to get much feedback.

Request for help for wierd relaying...

[fp145]

I have set up a postfix/dovecot/roundcube server on an Ubuntu box. 
Everything works fine *except* that my personal account on that machine
cannot send mail to another account I have on a different machine. 
Instead, it's delivered back to the sender.

Specifically, if the account fp...@libertyfp.org sends mail to
bi...@billoblog.com, the mail is delivered to fp...@libertyfp.org.

This is specific to this particular pair.  If I send email, for
instance, from fp...@libertyfp.org to oli...@billoblog.com, it's
delivered to oli...@billoblog.com.

Mail *from* bi...@billoblog.com to fp...@libertyfp.org gets delivered
fine.


Here's what my syslog says:


Aug 18 02:58:09 libertyfp postfix/qmgr[9675]: D0C4941E97:
from=, size=557, nrcpt=1 (queue active)

Aug 18 02:58:09 libertyfp dovecot: lmtp(11707): Connect from local

Aug 18 02:58:09 libertyfp dovecot:
lmtp(fp...@libertyfp.org)<11707><+TFjIyFbHGG7LQAAHPmxyw>:
msgid=<739649541ebad231caa0017671883c50c3810062.ca...@libertyfp.org>:
saved mail to INBOX

Aug 18 02:58:09 libertyfp postfix/lmtp[11706]: D0C4941E97:
to=, orig_to=,
relay=mail.libertyfp.org[private/dovecot-lmtp], delay=0.96,
delays=0.91/0.02/0.02/0.01, dsn=2.0.0, status=sent (250 2.0.0
 +TFjIyFbHGG7LQAAHPmxyw Saved)

Aug 18 02:58:09 libertyfp dovecot: lmtp(11707): Disconnect from local:
Client has quit the connection (state=READY)

***

The only recent change I made was to add a relay by sender line to
main.cf to relay @gmail, @charter and @hotmail through billoblog.com.
Apparently the vps I'm renting is in the middle of a bunch of dirty ip
addresses and I get blacklisted by association every few weeks and have
to appeal to get whitelisted again.  Rather than deal with that, I
decided to relay those addresses through another server of mine that is
assigned an ip address in a better neighborhood.

So... Here's what I added to main.cf:

#ADDED 08/10/2021 to relay mail to gmail through billoblog
sender_dependent_relayhost_maps = hash:/etc/postfix/bysender

and here's what's in /etc/postfix/bysender

% more bysender
*@gmail.com [mail.billoblog.com]:25
*@hotmail.com [mail.billoblog.com]:25
*@charter.com [mail.billoblog.com]:25

I can't figure out if this is a postfix issue or a dovecot issue.

Any pointers would be appreciated.


billo

Re: Today is a good day to DANE!

[raf]

On Tue, Aug 17, 2021 at 12:35:40PM -0400, Viktor Dukhovni 
 wrote:

> On Tue, Aug 17, 2021 at 06:12:04PM +1000, raf wrote:
> 
> > If you use Debian stable, and ISC Bind, it has just
> > become really really easy to implement DNSSEC for your
> > domain(s).
> 
> Indeed, BIND 9.16 makes it dramatically easier to sign your DNS zone and
> keep it signed reliably.  It automates ZSK rollover, and simplifies KSK
> rollover, including algorithm changes...
> 
> By all means please consider deploying DNSSEC for your zone.  As with
> any technology, don't just fire and forget, implement monitoring.  One
> tool I very much recommend is "ldns-verify-zone".  It can check all
> zone signatures, and whether any will expire too soon, ...

So far, I've just setup trivial monitoring (cron+sh+host)
that emails me whenever bind adds or removes KSK
DNSKEY/CDS/CDNSKEY records from the zones. That should
give me enough notice to know when I need to add/remove
DS records via the registrar.

But well thought out monitoring would be better. Thanks.

> > Once DNSSEC is sorted, DANE should be relatively easy. :-)
> > (unless you use LetsEncrypt)
> 
> There are two parts to implementing DANE, server and client.
> 
> - On the client side you just need a local (loopback) validating
>   resolver, your own zone need not be signed.  With that in place
>   enabling DANE in the Postfix SMTP client is easy.

A note about debian-11. libc no longer assumes that the AD flag
in DNS responses can be trusted. If it can be (i.e. if the only
name server is 127.0.0.1 and if it verifies), then you should add
"options trust-ad" to /etc/resolv.conf (or to whatever software
creates /etc/resolv.conf).

>   In http://www.postfix.org/TLS_README.html#client_tls_dane I
>   explained how to enable DANE selectively.  That was some time
>   back.  We should probably change the documentation to recommend:
> 
>   main.cf:
>   # Make sure /etc/resolv.conf lists only looopback nameservers,
>   # if you list remote nameservers, their "AD" bit is easily
>   # spoofed via active MiTM attacks.
>   #
>   smtp_dns_support_level = dnssec
>   smtp_tls_security_level = dane

Yes. I wondered why those settings weren't the default
recommendation rather than "may", but postfix doesn't
know anything about your resolver. It would be good
to document/recommend doing whatever it takes outside
postfix to be able to have those settings.

But the above comment should also mention the requirement that
the loopback nameserver must do dnssec validation. It might
still not be the default everywhere(?).

> - On the server side, no configuration changes in Postfix are
>   required beyond deploying TLS (with a certificate that
>   consistently matches the published DANE TLSA records).
> 
>   It is however critical to implement monitoring and a robust
>   key/cert rollover process from the get go, *before* you publish
>   your first TLSA RRset.  Take care of those first, and only
>   then publish TLSA records.
> 
>   See https://stats.dnssec-tools.org/ and the resources links at:
>   

Thanks.

> > LetsEncrypt (or rather certbot) doesn't play super-well with DANE (for
> > the way I want to do it - TLSA 3 1 1 records only, not TLSA 2 1 1
> > records). There are several old threads on community.letsencrypt.org
> > about DANE but I didn't find very clear actual instructions, but it's
> > still very useful to read. The last URL above (I think) gives the best
> > approach for my preference.
> 
> The key is to keep the key fixed unless and until you have TLSA records
> in place for the next planned key.  At that point, get Let's Encrypt to
> renew your certificate with that key.
> 
> The main difficulty is that Let's Encrypt makes it easy to keep the key
> fixed, or to generate a fresh random key (rather than a pre-configured
> key as needed here).  I need to polish and release my code that provides
> the missing functionality, and delays the key rollover until after the
> TLSA records have been in place for a sufficiently long time (multiple
> TTLs).
> 
> Let's Encrypt does have a "--csr" option that sophisticated users can
> use to implement the above, if you've already figured out how to do
> that, great.  Otherwise, just stick to a fixed key.

I'm not a certbot expert, but from what I've been reading, it seems that
--csr and renew are mutually exclusive. There are recommendations to
keep the key the same with certbot renew --reuse-key, but to occasionally
rollover the key with --csr. But I don't understand how that is supposed
to work. I'd like to see a tutorial with all the actual commands needed.

I'm currently effectively doing renew with reuse key until I work out
what to do for key rollovers, but I think what it has to be is that I
create a new separate key with --csr and and switch over to it and just
cron certbot --csr instead of certbot 

Re: Request for help for wierd relaying...

[Viktor Dukhovni]

On Tue, Aug 17, 2021 at 09:18:08PM -0400, fp145 wrote:

> Aug 18 02:58:09 libertyfp postfix/lmtp[11706]: D0C4941E97:
>to=, orig_to=,
>relay=mail.libertyfp.org[private/dovecot-lmtp], delay=0.96,
>delays=0.91/0.02/0.02/0.01, dsn=2.0.0, status=sent (250 2.0.0
> +TFjIyFbHGG7LQAAHPmxyw Saved)

This unequivocally shows that you have a virtual(5) aliases rewrite rule
mapping "bi...@billoblog.com" to "fp...@libertyfp.org", if that's not
what you actually want, delete the rule from virtual alias tables.

> sender_dependent_relayhost_maps = hash:/etc/postfix/bysender

Whatever, not directly relevant to your problem...

> and here's what's in /etc/postfix/bysender
> 
> % more bysender
> *@gmail.com [mail.billoblog.com]:25
> *@hotmail.com [mail.billoblog.com]:25
> *@charter.com [mail.billoblog.com]:25

That's not valid syntax for that table, these are not ever used as
written.  As can't have seen the above syntax documented, one might
wonder how you arrived at that particular form... See postconf(5):

sender_dependent_relayhost_maps (default: empty)
   A sender-dependent override for the global relayhost parameter setting.
   The tables are searched by the envelope sender address and @domain. A
   lookup result of DUNNO terminates the search without overriding the
   global relayhost parameter setting (Postfix 2.6 and later). This
   information is overruled with relay_transport,
   sender_dependent_default_transport_maps, default_transport and with the
   transport(5) table.

   Specify zero or more "type:name" lookup tables, separated by whitespace
   or comma. Tables will be searched in the specified order until a match
   is found.

   For safety reasons, this feature does not allow $number substitutions
   in regular expression maps.

   This feature is available in Postfix 2.3 and later.

-- 
Viktor.

AW: Google spam...

[ludicree]

Google does not honor abuse addresses, or spamcop. 

Which makes it the #1 scammer paradise.

Greets,
Ludi


-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im 
Auftrag von Vince Heuser
Gesendet: Mittwoch, 18. August 2021 02:06
An: postfix-users@postfix.org
Betreff: Re: Google spam...

What's the matter with ab...@google.com  and at spamcop.net?




On 2021/08/17 17:35 PM, Viktor Dukhovni wrote:
>> On 17 Aug 2021, at 5:13 pm, SH Development  
>> wrote:
>>
>> We have been getting inundated by spam from Google (gmail).
>>
>> I know that if our server gets reported for even a few spammy messages, 
>> Google won’t hesitate to block our server.
>>
>> Short of blocking Google on our server, is there some place to report spam 
>> we have received from the Google platform?
> Yes, but I doubt it would have any meaningful effect. :-(
>
> You can (with much manual effort) fill in Google's abuse report form:
>
>   https://support.google.com/mail/contact/abuse
>
> or (easier, but no idea whether this is effective), use an IMAP client 
> to move the message into the INBOX of a Gmail account, and then report 
> it as spam.
>
> Unless you have friends in high places at Gmail, or manage to get law 
> enforcement interested, you're unlikely to get much feedback.
>

Re: Google spam...

[Viktor Dukhovni]

On Wed, Aug 18, 2021 at 07:27:38AM +0200, ludic...@gmail.com wrote:

> Google does not honor abuse addresses, or spamcop. 
> 
> Which makes it the #1 scammer paradise.

The key problem is that email accounts are free, and the 419 scammers
are not bots, and so it is difficult to prevent them from opening a new
account.  Ideally their messages would trigger outbound filtering when
composed, but stopping them must be harder than one would naïvely
expect, and conveniently for the big email hosters, not a problem
they need to solve.

The scammer just needs to avoid sending spam to any Gmail users from
a Gmail account, and everyone else has no effective way to complain.

Another barrier to effectively shutting them down is that much of the
junk is sent via various other outbound services, with just the
Reply mailbox on Gmail (or similar).  It is then difficult to convice
Google to shut down a mailbox that is not even directly a sender of
the junk.

Externalities are great when you're not the one on the hook for the
costs.

-- 
Viktor.

AW: Google spam...

[ludicree]

Yes, many of them are regular GUI users.

But also many of them do the same scheme for years now, sometimes for long 
periods with the same accounts.
Like the notorious "Maria Elisabeth Schaeffler" mass scam every day.

I do not believe Google does not know what goes on. They just don't care.

Other freemailers care and they are not abused in such amounts.

But if one wants to get rid of the Google scam to some degree:
Many use their campaign GMail as the Reply-To address.
Especially when sending from hacked accounts, but also when using other (new) 
GMail accounts.
I have yet to see a false positive while filtering that.

Greets,
Ludi


-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im 
Auftrag von Viktor Dukhovni
Gesendet: Mittwoch, 18. August 2021 07:41
An: postfix-users@postfix.org
Betreff: Re: Google spam...

On Wed, Aug 18, 2021 at 07:27:38AM +0200, ludic...@gmail.com wrote:

> Google does not honor abuse addresses, or spamcop. 
> 
> Which makes it the #1 scammer paradise.

The key problem is that email accounts are free, and the 419 scammers are not 
bots, and so it is difficult to prevent them from opening a new account.  
Ideally their messages would trigger outbound filtering when composed, but 
stopping them must be harder than one would naïvely expect, and conveniently 
for the big email hosters, not a problem they need to solve.

The scammer just needs to avoid sending spam to any Gmail users from a Gmail 
account, and everyone else has no effective way to complain.

Another barrier to effectively shutting them down is that much of the junk is 
sent via various other outbound services, with just the Reply mailbox on Gmail 
(or similar).  It is then difficult to convice Google to shut down a mailbox 
that is not even directly a sender of the junk.

Externalities are great when you're not the one on the hook for the costs.

-- 
Viktor.

Re: Request for help for wierd relaying...

[raf]

On Wed, Aug 18, 2021 at 12:43:55AM -0400, Viktor Dukhovni 
 wrote:

> > sender_dependent_relayhost_maps = hash:/etc/postfix/bysender
> 
> Whatever, not directly relevant to your problem...
> 
> > and here's what's in /etc/postfix/bysender
> > 
> > % more bysender
> > *@gmail.com [mail.billoblog.com]:25
> > *@hotmail.com [mail.billoblog.com]:25
> > *@charter.com [mail.billoblog.com]:25
> 
> That's not valid syntax for that table, these are not ever used as
> written.  As can't have seen the above syntax documented, one might
> wonder how you arrived at that particular form... See postconf(5):
> 
> sender_dependent_relayhost_maps (default: empty)
>A sender-dependent override for the global relayhost parameter setting.
>The tables are searched by the envelope sender address and @domain. A
>lookup result of DUNNO terminates the search without overriding the
>global relayhost parameter setting (Postfix 2.6 and later). This
>information is overruled with relay_transport,
>sender_dependent_default_transport_maps, default_transport and with the
>transport(5) table.
> 
>Specify zero or more "type:name" lookup tables, separated by whitespace
>or comma. Tables will be searched in the specified order until a match
>is found.
> 
>For safety reasons, this feature does not allow $number substitutions
>in regular expression maps.
> 
>This feature is available in Postfix 2.3 and later.
> 
> -- 
> Viktor.

Database files used with
sender_dependent_relayhost_maps need either an email
address or a @domain on the left hand side.

You are trying to use shell glob-style patterns instead
of email addresses or @domains. I don't think
glob-style patterns are a thing anywhere in postfix.
You might want to read
http://www.postfix.com/DATABASE_README.html
And always carefully read the documentation in
http://www.postfix.com/postconf.5.html for whatever
setting you are using.

So, if you really should be using
sender_dependent_relayhost_maps, then the left hand
side should just be "@gmail.com" etc., not "*@gmail.com".

But I think you probably shouldn't be using
sender_dependent_relayhost_maps at all.

Is this really about emails that have been sent *from*
gmail/hotmail/charter that are being relayed through
your server to another mail server, and that other mail
server is not accepting emails from your server because
of your IP reputation? It seems odd that a domain that
you relay for would be rejecting your server. Are you a
secondary MX for them or not?

I ask because I used to have a similar sounding problem
with Microsoft/Outlook refusing to accept mail from my
server for secret reasons they felt no need to share
with me. But the problem was getting mail *to* people
with outlook email addresses. The workaround was to use
transport_maps which maps recipient addresses to a
(next hop) transport (and organising access to another
mail server that I could send mail through).

So, instead of mapping *sender* addresses/domains to a
relayhost like you are trying, I mapped *recipient*
addresses to a transport (a transport is like a
relayhost but more flexible).

I may have misunderstood what your problem is, but it
sounded very similar to mine. If it is the same sort
of thing, perhaps what you need is something like this:

  main.cf:
  transport_maps = regexp:/etc/postfix/transport

  transport:
  /.*@(gmail|hotmail|charter)\.com/ relay:[mail.billoblog.com]

You won't need to run postmap for the transport file when
you change it (because it's a regexp database).

cheers,
raf

How to set up a shadow server

[Ron Garret]

Is there an easy way to tell postfix to send a copy of every message it 
receives to a “shadow server” in a way that preserves the SMTP envelope?  I’m 
trying to tune a spam filter on actual data, but I don’t want to do it on my 
production server because the tuning is likely to break things.

Thanks,
rg

Re: Today is a good day to DANE!

[Marcel de Riedmatten]

Le mercredi 18 août 2021 à 14:32 +1000, raf a écrit :
> 
> It would be great if certbot supported multiple simultaneous
> certificates
> for a domain, so that the next certificate could be ready in advance.
> Then pre/post/deploy hooks could take care of everything fairly
> easily.
> But I might have to wait for debian-12 or debian-13 for that. :-)

not sure. When creating the new certificate did you try to add 
--duplicate to the command line ? In case of name conflict certboot
will create a new directory ( ex smtp.example.com-0001 ) wherever it is
needed. I just try it with a --test-cert only but I expect  it to work
with a real cert.

from the doc

--duplicate       Allow making a certificate lineage that duplicates an
                  existing one (both can be renewed in parallel)
                  (default: False)


It is certbot 0.31 on ubuntu bionic.

-- 
Marcel de Riedmatten