Re: report from google relate to failed dkim

[Dominic Raferd]

Please bottom post on this list (and see below)

On 28 December 2017 at 07:05, Poliman - Serwis  wrote:
> For particular domain from report dkim works well. I checked it here
> http://dkimcore.org/c/keycheck. Mails from this domain are sent by
> s1.domain.net server. Should be dkim configured for domain name of the
> server which corresponds to IP mentioned earlier?
>
> 2017-12-28 7:46 GMT+01:00 Poliman - Serwis :
>>
>> All is clear but how setup dmarc per IP address of the server if dmarc is
>> based on spf and dkim which are based on particular domain?
>>
>> 2017-12-27 10:37 GMT+01:00 Dominic Raferd :
>>>
>>> On 27 December 2017 at 07:22, Poliman - Serwis  wrote:
>>> > I configured yesterday spf, dkim, dmarc for example.com. Today I got
>>> > report
>>> > in xml on my mailbox. Attached. One from addresses has dkim failed -
>>> > marked
>>> > in orange...

Setting spf should not be necessary if you are setting a dkim header
correctly in all the outgoing emails for the domain in question.
Indeed I would go further and say that setting an spf DNS record for
your domain is inadvisable when testing dmarc because it can mask
underlying dkim problems.

In order to pass dmarc alignment testing, opendkim needs to insert
into the outgoing email a dkim header with a signing domain (d=)
matching the domain in the internal 'From:' header. The server name or
ip that it has come from is irrelevant for dkim.

If your mail passes dkim check-summing and dkim alignment when tested
at its destination for dmarc, it will pass overall regardless of any
spf (and vice versa).

Re: reject spoofed emails on Postfix

[Dominic Raferd]

On 27 December 2017 at 13:31, Selcuk Yazar  wrote:
> Hi,
>
> We have Postfix 2.6.6 on Redhat. I installed open-spf , open-dmarc , and
> dkim. I think everything is fine, but we have e-mail spoofing :(
>
> how can i correct this ?
>
> thanks in advance
>
> Received-SPF: pass (spf2.spf.guru: Sender is authorized to use
> 'bounces+3150432-2a15-user=dom...@spf2.spf.guru' in 'mfrom' identity
> (mechanism 'include:sendgrid.net' matched)) receiver=domain;
> identity=mailfrom;
> envelope-from="bounces+3150432-2a15-user=dom...@spf2.spf.guru";
> helo=o1.7nf.fshared.sendgrid.net; client-ip=167.89.55.67
> DMARC-Filter: OpenDMARC Filter v1.3.2 mail.domain 261CB7BB9CD
> Received: from o1.7nf.fshared.sendgrid.net (o1.7nf.fshared.sendgrid.net
> [167.89.55.67])
> (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits))
> (No client certificate requested)
> by domain (Postfix) with ESMTPS id 261CB7BB9CD
> for ; Wed, 27 Dec 2017 16:16:31 +0300 (+03)
> DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=spf.guru;
> h=subject:from:to:mime-version:content-type; s=s1;
> bh=G4EhwYTkXUk041GBBhrYcd5Q5Vw=; b=Lq29h//IIcNVD8yK8GtjU6Cg2U9Tf
> DE8dC6/iuLLnFZdOmaqTYWsiVk1Z+k+EVAlz1CVXVashDtbDtiBHsNWJRnoKAgTd
> ETeeoHGxlbisFwGbinLbKFXrTow1CRPkBujdIWgTgL2d2ok5MRzfo0UdAuMO1xlM
> z8AIf6VCo8EnOs=
> Received: by filter0025p3mdw1.sendgrid.net with SMTP id
> filter0025p3mdw1-23352-5A439D2C-6
> 2017-12-27 13:16:28.133251847 + UTC
> Received: from spf.guru (192.239.195.35.bc.googleusercontent.com
> [35.195.239.192])
> by ismtpd0006p1lon1.sendgrid.net (SG) with ESMTP id Zh96E147TxWVqAnTFGlWbA
> for ; Wed, 27 Dec 2017 13:16:27.975 + (UTC)
> Message-ID: 
> Date: Wed, 27 Dec 2017 13:16:28 + (UTC)
> Subject: my emails
> From: po...@whatsapp.com

This question might be better directed to the opendmarc mailing list -
http://www.trusteddomain.org/mailman/listinfo/opendmarc-users.

I guess opendmarc and/or opendkim is not configured correctly. Since
the internal 'From:' is @whatsapp.com I would expect opendmarc to have
rejected the email. Check in /etc/opendmarc.conf for:

RejectFailures true

Without this opendmarc runs in 'test' mode and won't reject anything.

I am also puzzled not to see any header from opendkim, this is
required by opendmarc (which cannot perform its own dkim checks). So
check if opendkim is working correctly, it should be heading a header
to emails before they are passed to opendmarc. The AuthServID used by
opendkim in this header should set in /etc/opendmarc.conf at
'TrustedAuthServIDs' so that this header info (and not any other dkim
headers) can be trusted by opendmarc.

BTW, since you have openDMARC 1.3.2 I suggest you use in /etc/opendmarc.conf:

SPFIgnoreResults True
SPFSelfValidate True

This would mean you no longer have to worry about (and can remove from
your setup) the separate spf checking - openDMARC will do its own
(which was unreliable in earlier versions).

Re: report from google relate to failed dkim

[Poliman - Serwis]

For particular domain from report dkim works well. I checked it here
http://dkimcore.org/c/keycheck. Mails from this domain are sent by
s1.domain.net server. Should be dkim configured for domain name of the
server which corresponds to IP mentioned earlier?

2017-12-28 7:46 GMT+01:00 Poliman - Serwis :

> All is clear but how setup dmarc per IP address of the server if dmarc is
> based on spf and dkim which are based on particular domain?
>
> 2017-12-27 10:37 GMT+01:00 Dominic Raferd :
>
>> On 27 December 2017 at 07:22, Poliman - Serwis  wrote:
>> > I configured yesterday spf, dkim, dmarc for example.com. Today I got
>> report
>> > in xml on my mailbox. Attached. One from addresses has dkim failed -
>> marked
>> > in orange...
>>
>> This is a DMARC report from Gmail and so a more appropriate place to
>> ask about it is the opendmarc mailing list
>> http://www.trusteddomain.org/mailman/listinfo/opendmarc-users. The
>> google link within the report that you attached gives a bit more
>> information. The report says that Gmail received one email purporting
>> to be from your domain, it passed the spf test and failed the dkim
>> test. If you are confident that this was a legitimate email (it came
>> from or via 200.150.100.50, unless you obfuscated this), then either
>> there is a problem with your dkim setup or this email bypassed it
>> entirely.
>>
>> DMARC reports from mail providers are very useful in checking for
>> problems with spf/dkim/dmarc before one moves to p=reject. Consider
>> using one of the services that receive and collate these reports for
>> you, it makes them easier to understand.
>>
>
>
>
> --
>
> *Pozdrawiam / Best Regards*
> *Piotr Bracha*
>



-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*

Re: report from google relate to failed dkim

[Poliman - Serwis]

All is clear but how setup dmarc per IP address of the server if dmarc is
based on spf and dkim which are based on particular domain?

2017-12-27 10:37 GMT+01:00 Dominic Raferd :

> On 27 December 2017 at 07:22, Poliman - Serwis  wrote:
> > I configured yesterday spf, dkim, dmarc for example.com. Today I got
> report
> > in xml on my mailbox. Attached. One from addresses has dkim failed -
> marked
> > in orange...
>
> This is a DMARC report from Gmail and so a more appropriate place to
> ask about it is the opendmarc mailing list
> http://www.trusteddomain.org/mailman/listinfo/opendmarc-users. The
> google link within the report that you attached gives a bit more
> information. The report says that Gmail received one email purporting
> to be from your domain, it passed the spf test and failed the dkim
> test. If you are confident that this was a legitimate email (it came
> from or via 200.150.100.50, unless you obfuscated this), then either
> there is a problem with your dkim setup or this email bypassed it
> entirely.
>
> DMARC reports from mail providers are very useful in checking for
> problems with spf/dkim/dmarc before one moves to p=reject. Consider
> using one of the services that receive and collate these reports for
> you, it makes them easier to understand.
>



-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*

Re: question on fallback transport usage

[Viktor Dukhovni]

> On Dec 27, 2017, at 8:42 PM, l carr  wrote:
> 
> The domains are not defined under mydestination, they are defined under
> virtual_alias_domains. So it sounds like the fallback_transport may not
> work for us. Is there any other way to accomplish that same scenario?

Just change move the domains from virtual_alias_domains to relay_domains:

 main.cf:
   indexed = ${default_database_type}:${config_directory}/
   parent_domain_matches_subdomains = smtpd_access_maps
   relay_domains = ldap-complete.example
   relay_transport = relay:[legacy-server.example]
   virtual_alias_domains = ldap-incomplete.example
   virtual_alias_maps = ldap:${config_directory}/ldap-valias.cf

   # If you have no list of valid recipients, as a last resort
   # accept all relay recipients
   #
   relay_recipient_maps = static:all

   # Otherwise deploy some suitable table that lists all valid
   # recipients.
   #
   # relay_recipient_maps = ...

This works because virtual alias domains always rewrite into some
underlying domain for delivery, which works already.  So any remaining
recipients that don't get rewritten can be handled via relay_transport
after changing the problem domains to relay_domains.  After all the
problem recipients are resolved, move them back to the virtual alias
domains list.

You might end up with a bit of a backscatter problem if you can't
enumerate valid recipients.  Don't let this fester.

-- 
Viktor.

Re: question on fallback transport usage

[Wietse Venema]

l carr:
> The domains are not defined under mydestination, they are defined
> under virtual_alias_domains. So it sounds like the fallback_transport
> may not work for us. Is there any other way to accomplish that
> same scenario?

That depends on what you mean with 'undeliverable'. Which Postfix
delivery agent logs the non-delivery, and what is logged as the
delivery status? You can anonymize the email address.

(Viktor and I are the main developers, so you're talking to the
right people).

Wietse

Re: question on fallback transport usage

[l carr]

The domains are not defined under mydestination, they are defined under 
virtual_alias_domains. So it sounds like the fallback_transport may not work 
for us. Is there any other way to accomplish that same scenario?


=lc



From: owner-postfix-us...@postfix.org  on 
behalf of Viktor Dukhovni 
Sent: Wednesday, December 27, 2017 5:31 PM
To: Postfix users
Subject: Re: question on fallback transport usage



> On Dec 27, 2017, at 5:15 PM, l carr  wrote:
>
> What we would like to do, as a transitional state, is mimic the Sendmail 
> failover relay to re-direct undeliverable email from the Postfix system to 
> Server A. With Server A only handling emails redirected to it from the 
> Postfix server, this would allow us to more easily identify the edge cases.
>
> We think we could do this using fallback transport but before we go too deep, 
> we'd like to see if anyone else has tried that and if it's a good idea or if 
> anyone has a better way to tackle that scenario. In our scenario, we would 
> only use the fallback transport until we completed migrating to the new 
> system.

The "fallback_transport" setting is a feature of the local(8)
delivery agent, when it finds no alias or local user matching
the localpart of the email address.

If all the problem messages are for a domain in mydestination,
and fail to find a matching "alias" in local delivery, then
indeed fallback_transport might do the trick.

--
Viktor.

Re: Postfix RPMs

[Peter]

On 28/12/17 07:54, flowhosts wrote:
> Per security policy i am not allowed to use sources besides redhats...

That's understandable.

> I do build postfix from source using the specs file available in fedora
> repo.
> It is simple, just install rpbmuild grab the tar.gz file and rename
> everything in the spec file to match your distro.
> Build with rpbmuild -ba postfix.spec

That's probably the next best option given a policy like the above,
although I would recommend using mock instead which will give you a
clean build environment and automatically pull in build dependencies.
Mock is available from both the CentOS extras repo and epel.

The sources are also freely available from GhettoForge if you want to
look them over.


Peter

Re: question on fallback transport usage

[Viktor Dukhovni]

> On Dec 27, 2017, at 5:15 PM, l carr  wrote:
> 
> What we would like to do, as a transitional state, is mimic the Sendmail 
> failover relay to re-direct undeliverable email from the Postfix system to 
> Server A. With Server A only handling emails redirected to it from the 
> Postfix server, this would allow us to more easily identify the edge cases.
> 
> We think we could do this using fallback transport but before we go too deep, 
> we'd like to see if anyone else has tried that and if it's a good idea or if 
> anyone has a better way to tackle that scenario. In our scenario, we would 
> only use the fallback transport until we completed migrating to the new 
> system.

The "fallback_transport" setting is a feature of the local(8)
delivery agent, when it finds no alias or local user matching
the localpart of the email address.

If all the problem messages are for a domain in mydestination,
and fail to find a matching "alias" in local delivery, then
indeed fallback_transport might do the trick.

-- 
Viktor.

question on fallback transport usage

[l carr]

Hi All -

Here's our scenario.

Migrating from server A to server B. Server A is a proprietary system that uses 
LDAP queries for delivering email. Server B is a Postfix system configured to 
deliver email using LDAP queries, mirroring as closely as possible, Server A.

In testing, the Postfix server appears to be processing a large majority of 
mail correctly but we keep running into 'edge cases' where Postfix fails on 
delivering an email that the original server is able to deliver successfully. 
We have tried tracking these edge case failures through the mail logs, and 
correcting them as we find them, but we still run into these cases here and 
there.

What we would like to do, as a transitional state, is mimic the Sendmail 
failover relay to re-direct undeliverable email from the Postfix system to 
Server A. With Server A only handling emails redirected to it from the Postfix 
server, this would allow us to more easily identify the edge cases.

We think we could do this using fallback transport but before we go too deep, 
we'd like to see if anyone else has tried that and if it's a good idea or if 
anyone has a better way to tackle that scenario. In our scenario, we would only 
use the fallback transport until we completed migrating to the new system.

thanks in advance.

Re: Postfix RPMs

[flowhosts]

Per security policy i am not allowed to use sources besides redhats...

I do build postfix from source using the specs file available in fedora 
repo.
It is simple, just install rpbmuild grab the tar.gz file and rename 
everything in the spec file to match your distro.

Build with rpbmuild -ba postfix.spec

Greets

On 27.12.17 18:21, Nikolaos Milas wrote:

On 27/12/2017 4:34 μμ, Rosenbaum, Larry M. wrote:


Where can I get up-to-date Postfix installation RPMs?



I would suggest you to use GhettoForge repo 
(http://ghettoforge.org/index.php/Main_Page);


See packages: http://ghettoforge.org/index.php/Postfix3

Cheers,
Nick

Re: No/Invalid host lookup in smtpd_sasl_path parameter

[Wietse Venema]

Lorenzo Bernardi:
> It looks like "libnss_dns.so.2" cannot be found due to the chrooted 
> environment and thus no DNS query can be made (at least for this 
> specific call).
> I fixed it by copying the libraries from /lib/x86_64-linux-gnu/ to 
> /var/spool/postfix/lib/x86_64-linux-gnu/:
> 
> > cp /lib/x86_64-linux-gnu/ /var/spool/postfix/lib/ -R

The problem with making a copy of libnss_dns.so is that the copy
will become outdated, unless the files are (r)synced at regular
times from the host into /var/spool/postfix. Ditto with /etc/{services,
resolv.conf, nsswitch.conf, host.conf, hosts, localtime} and so on.

> This apparently worked as postfix is now able to make DNS queries:
> Shouldn't this be documented somewhere for other people that might 
> encounter the issue?

The chroot feature is documented in the master(5) manpage which
describes the master.cf file format.

   Chroot (default: Postfix >= 3.0: n, Postfix <3.0: y)
  Whether or not the service  runs  chrooted  to  the  mail  queue
  directory (pathname is controlled by the queue_directory config-
  uration variable in the main.cf file).

  Chroot should not be used with the local(8), pipe(8),  spawn(8),
  and virtual(8) daemons.  Although the proxymap(8) server can run
  chrooted, doing so defeats most of the purpose  of  having  that
  service in the first place.

  The files in the examples/chroot-setup subdirectory of the Post-
  fix source archive show set up a Postfix chroot environment on a
  variety  of  systems.  See  also  BASIC_CONFIGURATION_README for
  issues related to running daemons chrooted.

The examples/chroot-setup files have not been updated in many years.
Every system and every version is different, so use this information
as inspiration, not as gospel.

Wietse

Re: Postfix RPMs

[Nikolaos Milas]

On 27/12/2017 4:34 μμ, Rosenbaum, Larry M. wrote:


Where can I get up-to-date Postfix installation RPMs?



I would suggest you to use GhettoForge repo 
(http://ghettoforge.org/index.php/Main_Page);


See packages: http://ghettoforge.org/index.php/Postfix3

Cheers,
Nick

Re: No/Invalid host lookup in smtpd_sasl_path parameter

[Lorenzo Bernardi]

Thank you Wietse,

I followed your advice and ran a strace on the smtpd process.

Postfix is running in a chroot environment (/var/spool/postfix) and I 
noticed the following:


Dec 27 16:55:05 85b8d58a343c root: open("/etc/resolv.conf", 
O_RDONLY|O_CLOEXEC) = 18
Dec 27 16:55:05 85b8d58a343c root: fstat(18, {st_mode=S_IFREG|0644, 
st_size=60, ...}) = 0
Dec 27 16:55:05 85b8d58a343c root: read(18, "search 
openstacklocal\nnameserver 127.0.0.11\noptions ndots:0\n", 4096) = 60
Dec 27 16:55:05 85b8d58a343c root: read(18, "", 4096)   
   = 0
Dec 27 16:55:05 85b8d58a343c root: close(18)
   = 0
Dec 27 16:55:05 85b8d58a343c root: open("/etc/host.conf", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: futex(0x7f9690f79a64, 
FUTEX_WAKE_PRIVATE, 2147483647) = 0
Dec 27 16:55:05 85b8d58a343c root: open("/etc/hosts", 
O_RDONLY|O_CLOEXEC)  = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: open("/etc/ld.so.cache", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
open("/lib/x86_64-linux-gnu/tls/x86_64/libnss_dns.so.2", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
stat("/lib/x86_64-linux-gnu/tls/x86_64", 0x7ffc42960c30) = -1 ENOENT 
(No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
open("/lib/x86_64-linux-gnu/tls/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: stat("/lib/x86_64-linux-gnu/tls", 
0x7ffc42960c30) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
open("/lib/x86_64-linux-gnu/x86_64/libnss_dns.so.2", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: stat("/lib/x86_64-linux-gnu/x86_64", 
0x7ffc42960c30) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
open("/lib/x86_64-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: stat("/lib/x86_64-linux-gnu", 
0x7ffc42960c30) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
open("/usr/lib/x86_64-linux-gnu/tls/x86_64/libnss_dns.so.2", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
stat("/usr/lib/x86_64-linux-gnu/tls/x86_64", 0x7ffc42960c30) = -1 
ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
open("/usr/lib/x86_64-linux-gnu/tls/libnss_dns.so.2", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
stat("/usr/lib/x86_64-linux-gnu/tls", 0x7ffc42960c30) = -1 ENOENT (No 
such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
open("/usr/lib/x86_64-linux-gnu/x86_64/libnss_dns.so.2", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
stat("/usr/lib/x86_64-linux-gnu/x86_64", 0x7ffc42960c30) = -1 ENOENT 
(No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
open("/usr/lib/x86_64-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: stat("/usr/lib/x86_64-linux-gnu", 
0x7ffc42960c30) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
open("/lib/tls/x86_64/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: stat("/lib/tls/x86_64", 
0x7ffc42960c30) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: open("/lib/tls/libnss_dns.so.2", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: stat("/lib/tls", 0x7ffc42960c30) 
   = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: open("/lib/x86_64/libnss_dns.so.2", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: stat("/lib/x86_64", 0x7ffc42960c30)  
   = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: open("/lib/libnss_dns.so.2", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: stat("/lib", {st_mode=S_IFDIR|0755, 
st_size=4096, ...}) = 0
Dec 27 16:55:05 85b8d58a343c root: 
open("/usr/lib/tls/x86_64/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: stat("/usr/lib/tls/x86_64", 
0x7ffc42960c30) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: open("/usr/lib/tls/libnss_dns.so.2", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: stat("/usr/lib/tls", 0x7ffc42960c30) 
   = -1 ENOENT (No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 
open("/usr/lib/x86_64/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
Dec 27 16:55:05 85b8d58a343c root: 

Re: No/Invalid host lookup in smtpd_sasl_path parameter

[Wietse Venema]

Lorenzo Bernardi:
> Hi Wietse,
> 
> Thank you for your answer.
> 
> The docker containers are running Debian 9.3 and the postfix package 
> from the official Debian repository (Version: 3.1.6-0+deb9u1).
> 
> As you can see below the source code still contains calls to 
> gethostbyname():

Grep does not prove that code is called. The only gethostbyname
calls that are left over in the code are in src/local/biff_notify.c
and in src/util/find_inet.c, and the latter is called only by the
dict_mysql.c module. None of these calls are relevant for the problem
at hand: hooking up Postfix with the Dovecot auth service.

> Regarding the docker network, I followed the recommendations of the 
> official website and I'm using a user-defined network, which works with 
> no issue.

You made a mistake somewhere, because the SYSTEM LIBRARY FUNCTION
getaddrinfo() is unable to find your dovecot host unless you add
it to /etc/hosts.

To be totally clear about this: Postfix does not look in /etc/hosts,
it is the SYSTEM LIBRARY that reads the file, as configured in the
SYSTEM CONFIGURATION file /etc/nsswitch.conf.

See www.postfix.org/DEBUG_README.html for how to trace a program
with strace and ltrace, then you can see which call is failing and
why.

Wietse

Postfix RPMs

[Rosenbaum, Larry M.]

Where can I get up-to-date Postfix installation RPMs?

Thanks, Larry

Larry M. Rosenbaum
Oak Ridge National Laboratory

reject spoofed emails on Postfix

[Selcuk Yazar]

Hi,

We have Postfix 2.6.6 on Redhat. I installed open-spf , open-dmarc , and
dkim. I think everything is fine, but we have e-mail spoofing :(

how can i correct this ?

thanks in advance

Received-SPF: pass (spf2.spf.guru: Sender is authorized to use
'bounces+3150432-2a15-user=dom...@spf2.spf.guru' in 'mfrom' identity
(mechanism 'include:sendgrid.net' matched)) receiver=domain;
identity=mailfrom;
envelope-from="bounces+3150432-2a15-user=dom...@spf2.spf.guru";
helo=o1.7nf.fshared.sendgrid.net; client-ip=167.89.55.67
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.domain 261CB7BB9CD
Received: from o1.7nf.fshared.sendgrid.net
(o1.7nf.fshared.sendgrid.net [167.89.55.67])
(using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by domain (Postfix) with ESMTPS id 261CB7BB9CD
for ; Wed, 27 Dec 2017 16:16:31 +0300 (+03)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=spf.guru;
h=subject:from:to:mime-version:content-type; s=s1;
bh=G4EhwYTkXUk041GBBhrYcd5Q5Vw=; b=Lq29h//IIcNVD8yK8GtjU6Cg2U9Tf
DE8dC6/iuLLnFZdOmaqTYWsiVk1Z+k+EVAlz1CVXVashDtbDtiBHsNWJRnoKAgTd
ETeeoHGxlbisFwGbinLbKFXrTow1CRPkBujdIWgTgL2d2ok5MRzfo0UdAuMO1xlM
z8AIf6VCo8EnOs=
Received: by filter0025p3mdw1.sendgrid.net with SMTP id
filter0025p3mdw1-23352-5A439D2C-6
2017-12-27 13:16:28.133251847 + UTC
Received: from spf.guru (192.239.195.35.bc.googleusercontent.com
[35.195.239.192])
by ismtpd0006p1lon1.sendgrid.net (SG) with ESMTP id 
Zh96E147TxWVqAnTFGlWbA
for ; Wed, 27 Dec 2017 13:16:27.975 + (UTC)
Message-ID: 
Date: Wed, 27 Dec 2017 13:16:28 + (UTC)
Subject: my emails
From: *po...@whatsapp.com *

Re: Calendar & Contacts

[Liutauras Adomaitis]

Kolab - by default it is using Cyrus IMAP, not Dovecot. SMTP server is
Postfix by default. Supports *dav, ActiveSync. Roundcube as webmail.

Liutauras

On Wed, Dec 27, 2017 at 2:05 PM, Erwan David  wrote:

> Le 12/27/17 à 03:38, Mal a écrit :
> > Greetings..
> >
> > Interested to hear from those running a Postfix(MTA)/Dovecot(IMAP) combo
> > on what contacts & calendar server projects they are having success with.
> >
> > Mal
>
> I use nextcloud as contact & calendar server.
>
>

Re: Calendar & Contacts

[sirell]

Am 27.12.2017 um 03:38 schrieb Mal:
> Greetings..
> 
> Interested to hear from those running a Postfix(MTA)/Dovecot(IMAP) combo
> on what contacts & calendar server projects they are having success with.
> 
> Mal
> 
Hi,

We have Horde, flavor "webmail edition".
https://www.horde.org/apps/webmail

The most clients can be used with "ActiveSync" emulation embedded in
Horde. Only Outlook on mac (Entourage) has no ActiveSync (and no
plug-in/extension capability AFAIK). But these users tend to favor Apple
Mail and Calendar which both work.

Greets
Michael

Re: No/Invalid host lookup in smtpd_sasl_path parameter

[Lorenzo Bernardi]

Hi Wietse,

Thank you for your answer.

The docker containers are running Debian 9.3 and the postfix package 
from the official Debian repository (Version: 3.1.6-0+deb9u1).


As you can see below the source code still contains calls to 
gethostbyname():



postfix-3.1.6~ fgrep gethostbyname . -R -n
./proto/stop:603:gethostbyname
./auxiliary/name-addr-test/gethostbyname.c:2:  * gethostbyname tester. 
compile with:
./auxiliary/name-addr-test/gethostbyname.c:4:  * cc -o gethostbyname 
gethostbyname.c (SunOS 4.x)
./auxiliary/name-addr-test/gethostbyname.c:6:  * cc -o gethostbyname 
gethostbyname.c -lnsl (SunOS 5.x)
./auxiliary/name-addr-test/gethostbyname.c:8:  * run as: gethostbyname 
hostname
./auxiliary/name-addr-test/gethostbyname.c:29:if (hp = 
gethostbyname(argv[1])) {
./src/util/myaddrinfo.c:350:if ((hp = gethostbyname(hostname)) == 
0)

./src/util/find_inet.c:69:  if ((hp = gethostbyname(host)) == 0)
./src/smtp/smtp_addr.c:25:/*getnameinfo() or gethostbyname().
./src/local/biff_notify.c:69:	if ((hp = gethostbyname("localhost")) == 
0) {

./HISTORY:103:  gethostbyname() to look up its own machine name.  Sites
./HISTORY:6720:	hostname to "unknown". Some gethostbyname() 
implementations
./HISTORY:13578:	adding gethostbyname() calls that cause maildir 
delivery
./HISTORY:22047:	adding code that calls gethostbyname() to determine 
the


Regarding the docker network, I followed the recommendations of the 
official website and I'm using a user-defined network, which works with 
no issue.
I can correctly resolve the containers when in Debian by just using 
their name:



~ cat /etc/resolv.conf
search openstacklocal
nameserver 127.0.0.11
options ndots:0



~ cat /etc/hosts
127.0.0.1   localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.20.0.4  postfix



~ ping dovecot -c1
PING dovecot (172.20.0.5): 56 data bytes
64 bytes from 172.20.0.5: icmp_seq=0 ttl=64 time=0.165 ms
--- dovecot ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.165/0.165/0.165/0.000 ms



~ nslookup dovecot
Server: 127.0.0.11
Address:127.0.0.11#53

Non-authoritative answer:
Name:   dovecot
Address: 172.20.0.5


As said before, using the hostname and not the IP address of the dovecot 
container in the "virtual_transport" and "mailbox_transport" works:



# main.cf
...
mailbox_transport = lmtp:inet:dovecot:24
virtual_transport = lmtp:inet:dovecot:24
...


The issue here is the "smtpd_sasl_path " parameter.
When I set it this way, it doesn't resolve the hostname:


smtpd_sasl_path = inet:[dovecot]:12345


(I tried both with and without [])

But when I directly put the IP address:


smtpd_sasl_path = inet:[172.20.0.5]:12345


or add an hosts entry in /var/spool/postfix/etc/hosts:


172.20.0.5 dovecot


Everything works as expected

Kr,
Lorenzo

---
LORENZO BERNARDI

On 2017-12-27 00:51, wie...@porcupine.org wrote:


Lorenzo Bernardi:


I setup dovecot to handle SASL and listen on port 12345.
When I use the hostname in postfix configuration, I receive the
following error:
postfix/smtpd[141]: fatal: host/service dovecot/12345 not found: No
address associated with hostname


The getaddrinfo() SYSTEM LIBRARY routine, given hostname 'dovecot',
found no IP address. Postfix does not use gethostbyname() except
on systems that are more than 10 years old.


Everything also works correctly if I add the following entry in
/var/spool/postfix/etc/hosts:
172.20.0.5 dovecot


There should be no need to do that.

According to Docker documentation, "If you want containers to be
able to resolve IP addresses by container name, you should use
user-defined networks instead [of using the default bridge network]".

docs.docker.com/engine/userguide/networking/#the-default-bridge-network

Wietse

Re: Calendar & Contacts

[Erwan David]

Le 12/27/17 à 03:38, Mal a écrit :
> Greetings..
>
> Interested to hear from those running a Postfix(MTA)/Dovecot(IMAP) combo
> on what contacts & calendar server projects they are having success with.
>
> Mal

I use nextcloud as contact & calendar server.

Re: report from google relate to failed dkim

[Dominic Raferd]

On 27 December 2017 at 10:06, li...@lazygranch.com  wrote:
> On Wed, 27 Dec 2017 09:37:24 +
> Dominic Raferd  wrote:
>> ... DMARC reports from mail providers are very useful in checking for
>> problems with spf/dkim/dmarc before one moves to p=reject. Consider
>> using one of the services that receive and collate these reports for
>> you, it makes them easier to understand.
>
> I decided not to set up DMARC on my new server since the logs are
> pretty overwhelming. What service would you suggest?

I currently use http://dmarc.postmarkapp.com/ - you receive weekly
emails summarising the data, and it's free.

Re: report from google relate to failed dkim

[Juri Haberland]

On 27.12.2017 08:22, Poliman - Serwis wrote:
> I configured yesterday spf, dkim, dmarc for example.com. Today I got report
> in xml on my mailbox. Attached. One from addresses has dkim failed - marked
> in orange. What that means and how to fix it? I use ubuntu 16.04 lts and
> postfix:

Judging from the Google DMARC report I'd say that the server at
200.150.100.50 does not add a DKIM signature the outgoing mails - you need
to fix this.


 Juri

Re: report from google relate to failed dkim

[li...@lazygranch.com]

On Wed, 27 Dec 2017 09:37:24 +
Dominic Raferd  wrote:

> On 27 December 2017 at 07:22, Poliman - Serwis 
> wrote:
> > I configured yesterday spf, dkim, dmarc for example.com. Today I
> > got report in xml on my mailbox. Attached. One from addresses has
> > dkim failed - marked in orange...  
> 
> This is a DMARC report from Gmail and so a more appropriate place to
> ask about it is the opendmarc mailing list
> http://www.trusteddomain.org/mailman/listinfo/opendmarc-users. The
> google link within the report that you attached gives a bit more
> information. The report says that Gmail received one email purporting
> to be from your domain, it passed the spf test and failed the dkim
> test. If you are confident that this was a legitimate email (it came
> from or via 200.150.100.50, unless you obfuscated this), then either
> there is a problem with your dkim setup or this email bypassed it
> entirely.
> 
> DMARC reports from mail providers are very useful in checking for
> problems with spf/dkim/dmarc before one moves to p=reject. Consider
> using one of the services that receive and collate these reports for
> you, it makes them easier to understand.

I decided not to set up DMARC on my new server since the logs are
pretty overwhelming. What service would you suggest? 

BTW the OP should use this to verify the setup:
http://dkimvalidator.com/

There are a bunch of similar services, but I like the output on this
one.

I had some spammer try to spoof my email address and got a bounced
message because my they used my email address in the return. That was
a SPF rejection, but still nice to see the system working.
 

RE: Calendar & Contacts

[L . P . H . van Belle]

Hai, 

Kopano with nextcloud, z-push and webapp with files plugin rules here. 
Very good combo, bit harder to setup, but very compatible with lots of 
different devices. 

Greetz, 

Louis


> -Oorspronkelijk bericht-
> Van: li...@merit.unu.edu 
> [mailto:owner-postfix-us...@postfix.org] Namens mj
> Verzonden: woensdag 27 december 2017 10:54
> Aan: postfix-users@postfix.org
> Onderwerp: Re: Calendar & Contacts
> 
> We're very happy with sogo. (https://sogo.nu/)
> 
> MJ
> 
> On 12/27/2017 08:40 AM, Philip Paeps wrote:
> > On 2017-12-27 13:08:44 (+1030), Mal wrote:
> >> Interested to hear from those running a Postfix(MTA)/Dovecot(IMAP) 
> >> combo on what contacts & calendar server projects they are having 
> >> success with.
> > 
> > I run Nextcloud.
> > 
> > It's implemented in PHP (of all things) so you definitely 
> want to lock 
> > it up in a jail.  It stores its data in a PostgreSQL database (or 
> > possibly other kinds of databases -- I haven't looked).
> > 
> > If you're on FreeBSD, you can install it in a fresh jail with `pkg 
> > install nextcloud`.  The documentation is fairly comprehensive.
> > 
> > Philip
> > 
> 
> 

Re: Calendar & Contacts

[mj]

We're very happy with sogo. (https://sogo.nu/)

MJ

On 12/27/2017 08:40 AM, Philip Paeps wrote:

On 2017-12-27 13:08:44 (+1030), Mal wrote:
Interested to hear from those running a Postfix(MTA)/Dovecot(IMAP) 
combo on what contacts & calendar server projects they are having 
success with.


I run Nextcloud.

It's implemented in PHP (of all things) so you definitely want to lock 
it up in a jail.  It stores its data in a PostgreSQL database (or 
possibly other kinds of databases -- I haven't looked).


If you're on FreeBSD, you can install it in a fresh jail with `pkg 
install nextcloud`.  The documentation is fairly comprehensive.


Philip

Re: report from google relate to failed dkim

[Dominic Raferd]

On 27 December 2017 at 07:22, Poliman - Serwis  wrote:
> I configured yesterday spf, dkim, dmarc for example.com. Today I got report
> in xml on my mailbox. Attached. One from addresses has dkim failed - marked
> in orange...

This is a DMARC report from Gmail and so a more appropriate place to
ask about it is the opendmarc mailing list
http://www.trusteddomain.org/mailman/listinfo/opendmarc-users. The
google link within the report that you attached gives a bit more
information. The report says that Gmail received one email purporting
to be from your domain, it passed the spf test and failed the dkim
test. If you are confident that this was a legitimate email (it came
from or via 200.150.100.50, unless you obfuscated this), then either
there is a problem with your dkim setup or this email bypassed it
entirely.

DMARC reports from mail providers are very useful in checking for
problems with spf/dkim/dmarc before one moves to p=reject. Consider
using one of the services that receive and collate these reports for
you, it makes them easier to understand.