[P-U] Re: Postfix lists are migrating to a new list server

[Harald Koch via Postfix-users]

On Tue, Mar 7, 2023, at 12:02, Benny Pedersen via Postfix-users wrote:
>
> why is arc invalid ?

My email provider is adding a little more detail:

Authentication-Results: pb-mx20.pobox.com;
arc=invalid
  (as.1.list.sys4.de=invalid (public key: does not support hash algorithm 
'sha256'), ams.1.list.sys4.de=invalid (public key: does not support hash 
algorithm 'sha256'))
  smtp.remote-ip=188.68.34.52;

-- 
Harald Koch
c...@pobox.com
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Re: Forwarding best practices

[Harald Koch]

On Thu, Aug 6, 2020, at 09:53, Kris Deugau wrote:
> 
> I can only guess that the "Mark as spam" button looks a lot like a 
> "Delete" symbol of some kind, or I have to give up all hope of 
> intelligence on the part of end users.

In many of the email programs I use, J/K are the "next message/previous 
message" keyboard shortcuts.

In Outlook, J is the "Mark as Junk" shortcut.

I swear I hit it about once a day as I'm switching email clients ...

-- 
Harald Koch
c...@pobox.com

Re: should we use plaintext for message?

[Harald Koch]

On Wed, Mar 18, 2020, at 11:27, Darac Marjal wrote:

> Markdown is a very good step
> towards this, IMO.

Oh the irony...

>From the initial announcement of Markdown by John Gruber 
>(https://web.archive.org/web/20040402182332/http://daringfireball.net/projects/markdown/):

" the single biggest source of inspiration for Markdown’s syntax is the format 
of plain text email."

-- 
Harald

Re: best practice for HA cluster

[Harald Koch]

On Fri, Feb 8, 2019, at 06:40, Emmanuel Fusté wrote:
> 
> Never use shared storage. It will be your main source of problems.

Recognizing that shared storage is always a headache:

How do you handle the situation where your active node crashes with queued, 
undelivered messages?

-- 
Harald Koch
c...@pobox.com

Re: performance question

[Harald Koch]

On 25 June 2018 at 09:42, Matus UHLAR - fantomas  wrote:

>
> depends on how do you configure it. hash: should not have noticeable
> performance impact.
>

a linear search through 2000 addresses should not have a noticeable
performance impact either, compared to, say, network round-trip times...

-- 
Harald

Re: FWIW, port 465 gets standards-track blessing from RFC8314

[Harald Koch]

>
> I can't think of a single reason to have two submission ports.
>

Compatability with the clients that only implement one?

Re: [postfix-users] FWIW, port 465 gets standards-track blessing from RFC8314

[Harald Koch]

Is this change in long-standing opinion of the IETF only because existing
implementations so often ignore STARTTLS, or is there actually a security
issue with STARTTLS (instead of implicit TLS)?

-- 
Harald

Re: Self-signed TLS certificates (Minimal setup)

[Harald Koch]

On Wed, Jan 24, 2018, at 08:37, Dirk Stöcker wrote:
> 
> It's not sooo complicated:

The length of your message contradicts that statement.

(These days I recommend https://github.com/square/certstrap because it's
easily scripted. I'm currently using it in several ansible playbooks,
for example.)
-- 
Harald

Re: Question regarding Postfix virtual domains and SPF

[Harald Koch]

I solved this particular problem (forwarding third-party email to google)
using "postsrsd" https://github.com/roehling/postsrsd. SRS (Sender
Rewriting Scheme) rewrites the envelope sender address so that it appears
to be from your domain (allowing SPF to work). This is the scheme used by
forwarders like pobox.com (which is how I learned about it :)

It has drawbacks - for example, it rewrites all email (even messages that
are already from your domain). You might be able to configure around it ; I
run it on a dedicated VPS so I didn't have to investigate that part.

-- 
Harald


On 16 October 2017 at 22:05, J Doe  wrote:

> Hi,
>
> I have two questions regarding using SPF when I am using Postfix with
> virtual domain hosting.
>
> I currently have an SPF record in my DNS:
>
> example.comTXT“v=spf1 ip4:1.2.3.4/32 ip6:1:2:3::4/128 ?all”
>
> I virtually host a domain (in this example case, example.com), that is
> set to forward mail to recipients on Gmail.  As an example case, if I send
> an e-mail from a Hotmail account to an address on my server it then
> forwards that mail to the user’s GMail e-mail address.
>
> Path:   u...@hotmail.com — > example.com (virtual domain) — >
> u...@gmail.com
>
> When examining the e-mail details on GMail, I receive a “SOFTFAIL” for
> either the IPv4 or IPv6 of my server.  Farther down in the mail I see:
>
> (google.com: domain of transitioning u...@hotmail.com does not designate
> 1:2:3::4 as permitted sender)
>
> Testing mail that actually originates from the server (not forwarded
> through virtual hosting), with the “mail” program shows a PASS of SPF on
> GMail.
>
> My questions are:
>
> 1.  When using Postfix and virtual domain hosting in this fashion, is
> there any way to pass SPF when mail from a sending account is forwarded to
> another host (ie: Gmail) ?
>
> 2. Do I need to be concerned with a SPF SOFTFAIL from GMail when the same
> message generates a pass for DKIM (I have OpenDKIM configured and running
> correctly), and DMARC ?  In this case, does a SPF SOFTAIL but a DKIM and
> DMARC pass mean that SPF is always discounted and the mail won’t be
> quarantined ?
>
> Thanks for your help,
>
> - J
>

Re: Copying IMAP messages instead of Forwarding?

[Harald Koch]

This isn't an answer to your actual question, however:

I've been using postsrsd (https://github.com/roehling/postsrsd)
successfully to forward email in a similar situation - users with addresses
on my box that they want to be forwarded to a Gmail account. It has obvious
downsides, but it did solve the problem in my specific case, where google
was rejecting ~20% because of SPF failures.

-- 
Harald

Re: What user should be specified for the opendikm -u UID option?

[Harald Koch]

The info I posted earlier, about private keys read via a KeyTable - that
comes from the "FILE PERMISSIONS" section of the opendkim man page.

-- 
Harald

Re: What user should be specified for the opendikm -u UID option?

[Harald Koch]

Of course, it can't actually b this simple. None of this applies if you use
a KeyTable:

Thus, keys referenced by the KeyTable must always be accessible for read by
the unprivileged user.


Those keys are read at first use, not when the daemon starts up. *sigh. I
knew there was something I was forgetting.

-- 
Harald



On 3 September 2017 at 12:15, Harald Koch <c...@pobox.com> wrote:

> haha I was going to mention the Arch Wiki - it also gives misleading
> advice. Their improved setup has private keys owned by (and writable by!)
> the same user that the daemon runs as. Hacked daemon -> private key
> compromise.
>
> The default service file installed by the Arch package runs as root, btw,
> and drops privileges if you specify a "UserID" in the config file.
>
> --
> Harald
>
>
> On 3 September 2017 at 12:08, pgndev <pgnet@gmail.com> wrote:
>
>> fwiw, from Arch wiki
>>
>> https://wiki.archlinux.org/index.php/OpenDKIM
>> "The OpenDKIM daemon does not need to run as root at all (the
>> configuration suggested earlier will have OpenDKIM drop root privileges by
>> itself, but systemd can do this too and much earlier)."
>>
>> cat /etc/systemd/system/opendkim.service
>>   ...
>>   [Service]
>>   Type=forking
>>   User=opendkim
>>   Group=postfix
>>   ...
>>
>>
>>
>

Re: What user should be specified for the opendikm -u UID option?

[Harald Koch]

haha I was going to mention the Arch Wiki - it also gives misleading
advice. Their improved setup has private keys owned by (and writable by!)
the same user that the daemon runs as. Hacked daemon -> private key
compromise.

The default service file installed by the Arch package runs as root, btw,
and drops privileges if you specify a "UserID" in the config file.

-- 
Harald


On 3 September 2017 at 12:08, pgndev  wrote:

> fwiw, from Arch wiki
>
> https://wiki.archlinux.org/index.php/OpenDKIM
> "The OpenDKIM daemon does not need to run as root at all (the
> configuration suggested earlier will have OpenDKIM drop root privileges by
> itself, but systemd can do this too and much earlier)."
>
> cat /etc/systemd/system/opendkim.service
>   ...
>   [Service]
>   Type=forking
>   User=opendkim
>   Group=postfix
>   ...
>
>
>

Re: What user should be specified for the opendikm -u UID option?

[Harald Koch]

Just a small nit:

running opendkim as user opendkim in the systemd service file completely
defeats the ability of opendkim to drop privileges *after* reading the
private keys as root. I suspect most people aren't aware that having a
daemon start as root and drop privileges itself is a security feature?

Anyway, don't specify "User" and "Group" in the service file, but do use
the "-u opendkim" option. And then make the private keys owned by root.

-- 
Harald




On 3 September 2017 at 11:45, pgndev  wrote:

> fyi, if you prefer a dedicated user approach, just need to make sure
> you're consistent,
>
> groupdel opendkim
> groupadd opendkim
> useradd  opendkim -g opendkim -G "" -s /bin/false -d /var/run/opendkim -M
> usermod -a -G opendkim postfix
>
> id opendkim
> uid=5117(opendkim) gid=5117(opendkim) groups=5117(opendkim)
> id postfix
> uid=5001(postfix) gid=5001(postfix) groups=5001(postfix),12(mail),
> 5002(postdrop),...,5117(opendkim),...
>
>
> cat /etc/systemd/system/opendkim.service
> ...
> [Service]
> User=opendkim
> Group=opendkim
> Type=forking
> PIDFile=/var/run/opendkim/opendkim.pid
> ExecStart=/opt/opendkim/sbin/opendkim -l -x 
> /usr/local/etc/opendkim/opendkim.conf
> -u opendkim
> ...
>
> cat /usr/local/etc/opendkim/opendkim.conf
> ...
> UserIDopendkim:opendkim
> Socketlocal:/var/run/opendkim/opendkim.sock
> PidFile   /var/run/opendkim/opendkim.pid
> ...
>
> cat /usr/local/etc/opendkim/key_table
> dkim-56..._domainkey.example1.comexample1.com:dkim-56...:/usr/
> local/etc/sec/dkim/dkim-146...example1.com.key.pem
> dkim-0e..._domainkey.example2.comexample2.com:dkim-0e...:/usr/
> local/etc/sec/dkim/dkim-146...example2.com.key.pem
> ...
>
> ls -alr /var/run/opendkim
> total 4.0K
> srwxrwxr-x  1 opendkim opendkim0 Sep  2 09:33 opendkim.sock=
> -rw-r--r--  1 opendkim opendkim5 Sep  2 09:33 opendkim.pid
> drwxr-xr-x 42 root root 1.2K Sep  3 08:06 ../
> drwxr-xr-x  2 opendkim opendkim   80 Sep  2 09:33 ./
>
> ls -alr /usr/local/etc/opendkim
> total 40K
> -rw-rw-r--+  1 opendkim opendkim   93 May 30  2016 trusted_hosts
> -rw-r-+  1 opendkim opendkim 2.1K May 30  2016 signing_table
> -rw-r-+  1 opendkim opendkim 7.6K May 30 08:26 opendkim.conf
> -rw-r-+  1 opendkim opendkim 4.1K May 30  2016 key_table
> drwxrwxr-x+ 32 root root 4.0K Aug 28 07:30 ../
> drwxr-xr-x+  2 opendkim opendkim 4.0K May 30  2016 ./
>
> ls -al /usr/local/etc/sec/dkim
> total 384K
> drwxr-xr-x  2 opendkim opendkim  12K May 30  2016 ./
> drwxr-xr-x 10 root root 4.0K Aug 28 07:32 ../
> -rw---  1 opendkim opendkim 1.7K May 30  2016
> dkim-14...example1.com.key.pem
> -rw---  1 opendkim opendkim  451 May 30  2016
> dkim-14...example1.com.pubkey.pem
> -rw---  1 opendkim opendkim 1.7K May 30  2016
> dkim-14...example2.com.key.pem
> -rw---  1 opendkim opendkim  451 May 30  2016
> dkim-14...example2.com.pubkey.pem
> ...
>
> cat /usr/local/etc/postfix/master.cf
> ...
> [127.0.0.1]:10005 inet n - n - - smtpd
>   -o smtpd_milters=...,unix:/var/run/opendkim/opendkim.sock,...
> ...
> [int.mx.MYDOMAIN.COM]:587 inet n - n - - smtpd
>   -o smtpd_milters=...,unix:/var/run/opendkim/opendkim.sock,...
> ...
>
> cat /usr/local/etc/postfix/main.cf
> ...
> authorized_submit_users = ..., opendkim, ...
> ...
>
>
> works well here.
>
> hth.
>
>
>

Re: Puting the Postfix's queue into RAM disk

[Harald Koch]

On 13 November 2015 at 07:51, Istvan Prosinger  wrote:

>
> The point here is that at the start of this, a temporary deferred mail
> queue will build up signifficantly pushing most of the load on the file
> system, and the idea is to speed up the queue processing to prevent killing
> the server (extending the queue size it can process in a time frame)
> My client wouldn't make a problem to deliver the email after a week but
> I'm afraid that queue lifetime is out of the question (again, because of
> the queue size it would build up)
>

IME the only issue with queuing is the fsync() overhead when writing to the
queue. For the volumes you're talking about spinning disks might be slow,
but SSDs should be just fine. Everything else should already be cached in
memory by the operating system - in fact, using a tmpfs "steals" memory
that could be used for the OS disk buffer cache.

I think you will buy yourself a lot of (probably unnecessary) pain trying
to subvert Postfix's built-in reliability mechanisms.

(you mentioned using a VPS - all the major ones are 100% SSD these days, at
least here in North America. My Linode VPS is the fastest machine I have!
Also, I would expect modern VPS providers to be running battery-backed
caches down at the host layer - which means you'd already be running in
what is effectively an all-RAM scenario...)

-- 
Harald

Re: RC4 in live email servers?

[Harald Koch]

In my case It turned out to be me being incredibly stupid; I had

smtpd_tls_mandatory_exclude_ciphers = RC4

instead of

smtpd_tls_exclude_ciphers = RC4

yahoo.com is using AES128 now.

*looks embarrassed...*

-- 
Harald

Re: RC4 in live email servers?

[Harald Koch]

Maybe it's just a configuration error on my side, but all SMTP from
yahoo.com servers to mine still uses RC4...

-- 
Harald

Re: POODLE: smtpd_tls_mandatory_protocols question

[Harald Koch]

On 15 October 2014 17:06, Robert Schetterer r...@sys4.de wrote:


 doesnt look loosing much here

 4 SSLv3
   22353 TLSv1

 2 SSLv3
   17664 TLSv1


When I did this I saw about the same number of SSLv3 connections so I
looked at them in detail and every one was a SPAM attempt.

(RC4 on the other hand - Google and Yahoo are both still using it by
default... *sigh.)

-- 
Harald

Re: Blocking LinkedIn 'Intro' mail hijacking?

[Harald Koch]

On 25 October 2013 14:42, Charles Marcus cmar...@media-brokers.com wrote:

 Whether it is iOS specific or not (apparently it is, at least for the time
 being, iOS specific), it also applies to the smtp connection to my
 *postfix* server, so I disagree that it is OT.

 Apparently it is not a hoax, so the question remains, for those of us who
 do not have the enterprise tools to lock down iPhones and iPads, what is
 the best/most reliable way to simply block LinkedIn from being able to
 successfully connect to the SMTP server?


According to the technical description, they're modifying your inbound
email as you fetch it from your IMAP server, not your outbound email.

Still disturbing, but arguably completely off-topic for postfix...

Re: Blocking LinkedIn 'Intro' mail hijacking?

[Harald Koch]

On 25 October 2013 16:34, Charles Marcus cmar...@media-brokers.com wrote:

  Not according to this (from the second paragraph of the linked article):

 Once you install the Intro app, all of your emails, both sent and
 received, are transmitted via LinkedIn’s servers. LinkedIn is forcing all
 your IMAP and SMTP data through their own servers and then analyzing and
 scraping your emails for data pertaining to…whatever they feel like.


My bad - I was foolishly reading LinkedIn's technical article, not the
original. What can I say - it's Friday...

-- 
Harald

Re: email address (u...@domain.tld) as username?

[Harald Koch]

On 27 September 2013 05:32, Tomasz Chmielewski t...@virtall.com wrote:

 This system will however host 5 or so email accounts, that number
 will not grow, and I'd rather avoid extra complexity virtual setup
 brings (as virtual users for Postfix is one, and matching virtual users
 for the POP/IMAP server is another thing).


We've all heard that one before - I've even told it to myself. I now have
about a dozen accounts on my server.

It took me about 1/2 day to set up MySQL-based virtual users, complete with
mail delivery, SMTP auth, and IMAP/POP auth (this is why I went the
database route - it's easier than LDAP and both postfix and dovecot support
it). And it's been worth it - when a buddy says hey, can you setup an
email account for me? I can do it in seconds with one or two table edits.

-- 
Harald

Re: Someone is harassing my smtp.

[Harald Koch]

The internet is a swamp, and Relay access denied is relatively cheap - if
I were you I wouldn't waste valuable brain cells thinking about this, and
just ignore them.

Now if they're getting through your filters, that's a different story...

-- 
Harald

Re: Using Roundcube to send mail on localhost

[Harald Koch]

On 25/10/2011 5:29 PM, Seth Kneller wrote:

I have postfix and roundcube installed on the same server, postfix is
setup to use SASL auth and STARTTLS and I can send messages from
remote clients. However I cannot send messages from roundcube on the
localhost.

Can anyone help or point me to where to go next?


FWIW, I have roundcube configured with smtp_server set to 
'ssl://localhost' on port 465, instead of using tls://localhost on port 
587. I no longer recall whether that was because STARTTLS didn't work, 
or for some other reason...


--
Harald

Re: Should I have postgrey listen on a socket?

[Harald Koch]

On 05/12/2010 11:10 AM, Roger Marquis wrote:

I don't personally know why application designers tend to use localhost
IP ports instead of sockets, it's probably easier to code, but it is also
more difficult for end-users / systems admins to secure.



Generally speaking? Because some application users like to distribute 
their services across multiple servers - this is even more common in 
virtual data centers.


(ya, I know, a postgrey server can be run locally on every postfix 
server, but you did ask the slightly more general question. :)


--
Harald