Re: posttls-finger / DANE failure

[Viktor Dukhovni]

> On Oct 17, 2017, at 5:58 AM, Mal  wrote:
> 
> Bingo.  That information certainly explains the behavior observed.
> 
> Does this therefore require DNSSEC-validation to be set to "no" (for the
> authoritative NS):
>   dnssec-enable yes;

This must stay "yes" or else you DoS your domain.

>   dnssec-validation no;

This is ignored for authoritative zones, and useful for recursive
servers.  So long as your server continues to provide both authoritative
and recursive service (not a good idea), you should leave this in place.

The right thing to do is to deploy a separate validating recursive server,
use that in resolv.conf and then disable recursion in the authoritative
server, at which point this setting makes no difference.

>   dnssec-lookaside auto;

This is obsolete, the ISC DLV zone is now empty, so this should be set
to "no" in all recursive BIND servers.

-- 
Viktor.

Re: Syntax question for smtp mandatory TLS encryption

[Viktor Dukhovni]

> On Oct 18, 2017, at 12:45 AM, Viktor Dukhovni  
> wrote:
> 
> The documentation for the TLS policy table clearly states that the
> lookup key for the TLS policy is the *verbatim* nexthop.

http://www.postfix.org/TLS_README.html#client_tls_policy

The TLS policy table is indexed by the full next-hop destination,
which is either the recipient domain, or the verbatim next-hop
specified in the transport table, $local_transport, $virtual_transport,
$relay_transport or $default_transport. This includes any enclosing
square brackets and any non-default destination server port suffix.
The LMTP socket type prefix (inet: or unix:) is not included in the
lookup key.

The above leaves out content_filter or access(5) FILTER rules, as these
can also specify a non-default nexthop, but usually not one that's
subject to TLS encryption.  If you have a blanket encryption policy,
then you might actually need to exempt any loopback SMTP nexthop used
with content_filter and similar.

-- 
Viktor.

Re: Syntax question for smtp mandatory TLS encryption

[Viktor Dukhovni]

On Tue, Oct 17, 2017 at 11:03:46PM -0400, J Doe wrote:

> “The [] enclose a hostname which is to be looked up as a type A or 
>  record.  Without the [] first a lookup of type MX is done, and 
> where found, prioritized lookups of further hostnames (A or ) 
> would be done.

That's what they mean as a nexthop destination via the transport
table or similar.

> This is not specific to TLS, it is common to transport(5) and many 
> similar Postfix features.

The documentation for the TLS policy table clearly states that the
lookup key for the TLS policy is the *verbatim* nexthop.

So if the transport table reads:

example.com smtp:[smtp.example.com]:smtp

Then the TLS policy entry for that would have to be:

[smtp.example.com]:smtp...

exactly as specified in the transport table, or actual source
of nexthop information.

-- 
Viktor.

Re: Syntax question for smtp mandatory TLS encryption

[J Doe]

Hi Wietse,

> On Oct 11, 2017, at 7:11 PM, Wietse Venema  wrote:
> 
> J Doe:
>> Hi,
>> 
>> I have a syntax question regarding configuring mandatory TLS encryption for 
>> the smtp process as listed on: www.postfix.org/TLS_README.html#client_tls
>> 
>> In the second example on the page, square brackets are used when specifying 
>> the policy for specific destinations in the tls_policy file:
>> 
>> /etc/postfix/tls_policy
>>[example.net]:587 encrypt protocols=TLSv1 ciphers=high
> 
> You need the [] and the :587 in the lookup key, if that is what you
> specify as the destination in relayhost, transport_maps, etc.
> 
>Wietse

Thank you for your reply.

Ok, I understand that I would need that if the hostname was specified in 
relayhost, etc. but I am still confused as to what the square brackets mean.

A previous reply to this thread from /dev/rob0 (thanks rob0), states:

“The [] enclose a hostname which is to be looked up as a type A or 
 record.  Without the [] first a lookup of type MX is done, and 
where found, prioritized lookups of further hostnames (A or ) 
would be done.

This is not specific to TLS, it is common to transport(5) and many 
similar Postfix features.  The reason being, MX records exist to 
control mail routing.”

Does this mean that the square brackets determine the strategy for determining 
the address of the mail server ?

Thanks,

- J

Re: Question regarding Postfix virtual domains and SPF

[J Doe]

Hi /dev/rob0,

> On Oct 17, 2017, at 10:26 AM, /dev/rob0  wrote:

>> 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.
> 
> Another example to consider is when spam gets through your lines of 
> defense, and you forward that spam on to gmail.  El Goog thinks 
> you're the spam source, and they might block you!

For the volume of mail that this server processes and the amount of spam that 
gets forwarded to Google I haven’t run into being blocked outright.  Instead I 
receive an SMTP diagnostic message advising me of being rate limited.

Thanks,

- J

Re: Question regarding Postfix virtual domains and SPF

[J Doe]

Hi Viktor,

> On Oct 16, 2017, at 10:40 PM, Viktor Dukhovni  
> wrote:
> 
>> 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) ?
> 
> This requires SRS, and fairly effective anti-spam filters.  Much
> simpler to not support forwarding.

I did a quick search on Wikipedia and found the SRS article [1] which is fairly 
detailed - I will read through this over the next few days.

Thanks for the tip about effective anti-spam filters.

>> 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 ?
> 
> When the sending domain has both SPF and DKIM, you may be fine, as
> Google should be able to figure out that the message is a real
> hotmail message relayed through your system.  However, much depends
> on the details of the upstream DKIM signature and how it is processed
> by Gmail.

In the diagnostic messages in the message source, it appears that Google is 
doing that - determining that Hotmail is a valid source.  It still SOFTFAILS 
SPF but scores DKIM OK and thus concludes DMARC is ok.

Thanks,

- J

Sources:

[1] https://en.m.wikipedia.org/wiki/Sender_Rewriting_Scheme

Re: Feature Request: deduplication with multiple X-Original-To values

[Wietse Venema]

Rick van Rein:
> 3. With possibly multiple X-Original-To headers (or one header with
> multiple addresses) as a result of recipient deduplication
> (enable_original_recipient=collect)

Won't happen. By design, the code that writes queue files stores
final and original recipient information together, and forgets where
it is written. Adding more original recipients to a recipient would
require that it remembers where every recipient is written. Additionally,
features like DSN support only one original recipient per final recipient.

Wietse

Re: posttls-finger / DANE failure

[Mal]

On 18/10/2017 1:17 AM, /dev/rob0 wrote:

> Um, validation is exclusively done on NON-authoritative lookup 
> results.  I'm not sure what you are thinking.  In order:

This was pointed out previously.

> 1. dnssec-enable no; would prevent your BIND server from serving 
> required records from a signed zone.  It would prevent ANYONE from 
> being able to validate your signed zone.  This is surely not what 
> you're seeking?
Don't recall anyone suggesting this.

> 2. dnssec-validation no; again, this has no effect when you're 
> serving authoritative data from a master or slave zone.

This was my question to Viktor, "dnssec-validation no", based upon his
previous post.  I shall remove it.

Mal

Re: PSA: US government to set DMARC to reject

[Gary]

I'm of the opinion that the email client should indicate the presence of DKIM 
and SPF, then the user can decide what to do with the message. When I suggested 
this to Claws, I was encouraged to write my own plugin. I did learn Claws has a 
control-H feature to quickly display the header. Better than nothing I suppose. 

As a peon, I end up using web forms for government contact, so I'm not directly 
effected by this ruling. But if Gmail followed suit, reject would be a defacto 
standard. 

I've never set DMARC to reject, so I have no idea if the email is actually 
rejected in real life. I haven't attempted to get contacts to use DKIM or SPF. 
My effort is to get contacts to use TLS. I'm still down to one contact that 
doesn't want to break what is "working." 

Comcast has some issues with SPF. Sometimes it works, sometimes it doesn't. I 
haven't managed to get any Comcast customer to contact tech support about this, 
which to be fair is asking them to complain about some feature they don't 
understand. 

  Original Message  
From: m16+post...@monksofcool.net
Sent: October 17, 2017 10:37 AM
To: postfix-users@postfix.org
Subject: Re: PSA: US government to set DMARC to reject

On 17.10.17 19:07, Gary wrote:

> https://cyber.dhs.gov/
> Binding Operational Directive 18-01 enforces some basic email
> security, notably with DMARC set to reject.

Interesting choice of words there.

  DMARC [...] tells a recipient what the domain owner would like done
  with the message.

True so far. The next sentence however is

  Setting a DMARC policy of “reject” provides the strongest protection
  against spoofed email, ensuring that unauthenticated messages are
  rejected at the mail server, even before delivery.

"Would like" a message to be rejected of course does not "ensure" this
actually happens. That's a bad way to phrase an official US government
statement. The recipient alone decides, if he even supports DMARC in the
first place.

-Ralph

Re: PSA: US government to set DMARC to reject

[Ralph Seichter]

On 17.10.17 19:07, Gary wrote:

> https://cyber.dhs.gov/
> Binding Operational Directive 18-01 enforces some basic email
> security, notably with DMARC set to reject.

Interesting choice of words there.

  DMARC [...] tells a recipient what the domain owner would like done
  with the message.

True so far. The next sentence however is

  Setting a DMARC policy of “reject” provides the strongest protection
  against spoofed email, ensuring that unauthenticated messages are
  rejected at the mail server, even before delivery.

"Would like" a message to be rejected of course does not "ensure" this
actually happens. That's a bad way to phrase an official US government
statement. The recipient alone decides, if he even supports DMARC in the
first place.

-Ralph

PSA: US government to set DMARC to reject

[Gary]

https://cyber.dhs.gov

Binding Operational Directive 18-01 enforces some basic email security, notably 
with DMARC set to reject. Perhaps this will set a trend. Not necessarily for 
DMARC settings, but at least more servers will be set up properly not to be 
rejected. 

Re: OpenDKIM SOCK path on Debian Jessie

[Davide Marchi]

Il 2017-10-16 19:07 A. Schulze ha scritto:

[..]
postfix and sendmail/milter use different notation to describe the
same socket location.

http://www.postfix.org/MILTER_README.html#smtp-only-milters
vs.
http://opendkim.org/opendkim.conf.5.html (search for "Socket" ...)

to me your setup looks fine...
Andreas


Hi Andreas and thanks very very much for your help!
Very useful your information!
Of course, if the developers adopted a single standard would not be bad 
and it would save users a lot of time :-D


I've read many tutorials that do not keep track of this difference, I 
will write to the some editors.


Thanks again!


Davide

Re: posttls-finger / DANE failure

[/dev/rob0]

On Tue, Oct 17, 2017 at 08:28:02PM +1030, Mal wrote:
> On 17/10/2017 7:14 PM, Viktor Dukhovni wrote:
> 
> > So it seems that the machine in question has the authoritative 
> > server for the zone as its recursive server.  Such mixing of 
> > authoritative and recursive workloads is discouraged these days, 
> > and critically, it breaks DANE in Postfix for any authoritative 
> > zones, because authoritative servers are not validating 
> > resolvers, and don't set the AD bit in authoritative replies.
> 
> Bingo.  That information certainly explains the behavior observed.
> 
> Does this therefore require DNSSEC-validation to be set to "no"
> (for the authoritative NS):
>dnssec-enable yes;
>dnssec-validation no;
>dnssec-lookaside auto;

Um, validation is exclusively done on NON-authoritative lookup 
results.  I'm not sure what you are thinking.  In order:

1. dnssec-enable no; would prevent your BIND server from serving 
required records from a signed zone.  It would prevent ANYONE from 
being able to validate your signed zone.  This is surely not what 
you're seeking?

2. dnssec-validation no; again, this has no effect when you're 
serving authoritative data from a master or slave zone.

3. dnssec-lookaside has been removed!  Disable it now, on any 
nameservers you control.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Question regarding Postfix virtual domains and SPF

[/dev/rob0]

On Mon, Oct 16, 2017 at 10:05:07PM -0400, J Doe wrote:
> 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”
.^no dot?   ^ .. non-ASCII quote characters ... ^

Yes, probably just copy/paste errors, but attention to detail is 
important.

> I virtually host a domain (in this example case, example.com),
> that is set to forward mail to recipients on Gmail.

Usually "virtual" means "using the Postfix virtual(8) delivery 
agent," but clearly in this case you means something else, like a 
relay domain or virtual alias domain.

I don't get why, if you're wanting to read the mail via gmail, you 
don't just pay Google to host the domain?  That would be MUCH 
simpler.

> 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.

Another example to consider is when spam gets through your lines of 
defense, and you forward that spam on to gmail.  El Goog thinks 
you're the spam source, and they might block you!

(I'm leaving the SPF/DKIM/DMARC questions for others, but holding 
to the point that forwarding spam *will* cause big problems.)
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: posttls-finger / DANE failure

[Mal]

On 17/10/2017 7:14 PM, Viktor Dukhovni wrote:

> So it seems that the machine in question has the authoritative
> server for the zone as its recursive server.  Such mixing of
> authoritative and recursive workloads is discouraged these days,
> and critically, it breaks DANE in Postfix for any authoritative
> zones, because authoritative servers are not validating resolvers,
> and don't set the AD bit in authoritative replies.

Bingo.  That information certainly explains the behavior observed.

Does this therefore require DNSSEC-validation to be set to "no" (for the
authoritative NS):
   dnssec-enable yes;
   dnssec-validation no;
   dnssec-lookaside auto;


> The A record is not seen as "secure" by Postfix.

Got it.

> On my server the authoritative BIND nameserver listens on the 
> external public IP address, while the validating unbound resolver
> listens on 127.0.0.1 and the internal network interface.  The
> "/etc/resolv.conf" file lists 127.0.0.1, so DNS queries from
> applications go to unbound, not BIND.  The "unbound" server
> is configured to do DNSSEC validation, and queries BIND setting
> the "ad" bit as/when appropriate.
> 
> The BIND server refuses recursion, while the unbound server
> serves no authoritative zones.


Mal

Re: Jessie - Stretch to jump on Postfix 3.x

[Dominic Raferd]

​
For postfix it will be easy enough, just study http://www.postfix.org/
COMPATIBILITY_README.html.

I went from Ubuntu 14.04 (based on jessie and uses postfix 2.x) to 16.04
(based on stretch, uses postfix 3.x) a while ago, I had a few problems
relating to the change from upstart/sysinitv to systemd, but I think Jessie
(plain) already uses systemd by default so you won't have that hurdle to
jump.

Also for amavisd-new I had to change permission of /var/lib/spamassassin
directory to 755 - an alternative (untested by me) is to make user amavis a
member of debian-spamd group.
​

Feature Request: deduplication with multiple X-Original-To values

[Rick van Rein]

Hello,

Postfix currently allows two modes of operation when a message arrives
at the target more than once:

1. With recipient deduplication, but no X-Original-To
header(enable_original_recipient=yes)

2. With X-Original-To header, but no recipient deduplication
(enable_original_recipient=no)

Which desired behaviour most useful depends on the recipient -- some
recipients will benefit from the X-Original-To header [a service bot
with many names, for instance] and many others benefit from
deduplication [human list members, for instance].

The two desired behaviours seem unrelated, except for technical
reasons.  As a possible remedy that decouples the desires, I propose to
add a third mode:

3. With possibly multiple X-Original-To headers (or one header with
multiple addresses) as a result of recipient deduplication
(enable_original_recipient=collect)

This would benefit both use cases mentioned, making it less difficult to
choose from for email administrators.


I hope this is a useful suggestion :)


Thanks,

Rick van Rein
InternetWide.org / ARPA2.net / OpenFortress.nl

RE: Jessie - Stretch to jump on Postfix 3.x

[L . P . H . van Belle]

for me it was a good and easy upgrade from jessie to stretch. 
 
Things i needed  to change/run was this :  
 
# for postfix 
postconf compatibility_level=2 && postfix reload 
 
# for ntp
 sed -i 's/restrict -4 default kod notrap nomodify nopeer noquery/restrict -4 
default kod notrap nomodify nopeer noquery limited/g' /etc/ntp.conf
 sed -i 's/restrict -6 default kod notrap nomodify nopeer noquery/restrict -6 
default kod notrap nomodify nopeer noquery limited/g' /etc/ntp.conf  
and i did not like all language messages with apt. update in my logs ( own repo 
) 
 
if [ ! -e /etc/apt/apt.conf.d/99disable-translations ]; then
    echo "Adding disable translations for apt"
    echo "Acquire::Languages \"none\";" > 
/etc/apt/apt.conf.d/99disable-translations
else
 echo "No modication needed (apt disable-translations)"
fi
 
but thats about it. 
 
Good luck in upgrading, and this was for me, for you it may be different, that 
depends on the packages used. 
 
 
Greetz, 
Louis
 


Van: mauri...@caloro.ch [mailto:owner-postfix-us...@postfix.org] Namens 
Maurizio Caloro
Verzonden: dinsdag 17 oktober 2017 10:40
Aan: 'Postfix Users'
Onderwerp: Jessie - Stretch to jump on Postfix 3.x




Hello Together

 

I’am running with Debain Jessie 8.9, i play with the ideea upgrade the system 
8.9 ->Stretch.

Please existing here any complication, or/after the upgrade i need to 
reconfigure the hole mailserver?

 

I see that Stretch are armed with Postfix 3.x

 

I know this are not a specific Postfix question, but i am intressed to hear 
your expiriences!

 

Regards

Mauri

 

Re: posttls-finger / DANE failure

[Viktor Dukhovni]

> On Oct 17, 2017, at 3:58 AM, Mal  wrote:
> 
>> There's no such thing as "AD records". 
> 
> Was just a shortcut for 'Authoritative domain record'.

I've never seen that phrase before.

> The zone exists on that resolver and is queried directly.
> Will avoid lo[o]se english in future.

So it seems that the machine in question has the authoritative
server for the zone as its recursive server.  Such mixing of
authoritative and recursive workloads is discouraged these days,
and critically, it breaks DANE in Postfix for any authoritative
zones, because authoritative servers are not validating resolvers,
and don't set the AD bit in authoritative replies.  As seen below:

>> Post the (unobfuscated) output
> 
> malz@Woody:~$ domain="signsinc.com.au"
> malz@Woody:~$ dig +noall +comment +ans +auth +nocl +nottl -t mx "$domain."
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55931
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 8

No "ad" bit in the "flags:" field.

> signsinc.com.au.MX  20 access.signsinc.com.au.

So the MX record is not seen as "secure" by Postfix.

> malz@Woody:~$ for mx in $(dig +short -t mx $domain | sort -n | awk
> '{print $2}')
>> do
>>  dig +noall +comment +ans +auth +nocl +nottl -t a "$mx"
>>  dig +noall +comment +ans +auth +nocl +nottl -t  "$mx"
>>  dig +noall +comment +ans +auth +nocl +nottl -t tlsa "_25._tcp.$mx"
>> done
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37823
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

No "ad" bit here either.

> access.signsinc.com.au. A   150.101.252.86

The A record is not seen as "secure" by Postfix.

On my server the authoritative BIND nameserver listens on the 
external public IP address, while the validating unbound resolver
listens on 127.0.0.1 and the internal network interface.  The
"/etc/resolv.conf" file lists 127.0.0.1, so DNS queries from
applications go to unbound, not BIND.  The "unbound" server
is configured to do DNSSEC validation, and queries BIND setting
the "ad" bit as/when appropriate.

The BIND server refuses recursion, while the unbound server
serves no authoritative zones.

-- 
Viktor.

Jessie - Stretch to jump on Postfix 3.x

[Maurizio Caloro]

Hello Together

 

I'am running with Debain Jessie 8.9, i play with the ideea upgrade the
system 8.9 ->Stretch.

Please existing here any complication, or/after the upgrade i need to
reconfigure the hole mailserver?

 

I see that Stretch are armed with Postfix 3.x

 

I know this are not a specific Postfix question, but i am intressed to hear
your expiriences!

 

Regards

Mauri

 

AW: Ban IP or Host

[Maurizio Caloro]

Hello Mauricio

>  Have you tried fail2ban?

Yes, i have installed and configured, this are realy a helping and usefully 
tool!
Thanks for your fast answer!
Maurizio

Re: posttls-finger / DANE failure

[Mal]

On 17/10/2017 5:11 PM, Viktor Dukhovni wrote:

> The only way to find out they don't exist is to ask.

Very good.

> No TLSA records were found, perhaps because the "A" records were
> reported insecure, or because the TLSA records don't exist.

TLSA record is present.  The sys4 Dane SMTP validator gives me three
green boxes.  It lists the usable TLSA record.

> There's no such thing as "AD records". 

Was just a shortcut for 'Authoritative domain record'.  The zone exists
on that resolver and is queried directly.  Will avoid lose english in
future.

> Post the (unobfuscated) output

malz@Woody:~$ domain="signsinc.com.au"
malz@Woody:~$ dig +noall +comment +ans +auth +nocl +nottl -t mx "$domain."
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55931
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; ANSWER SECTION:
signsinc.com.au.MX  20 access.signsinc.com.au.

;; AUTHORITY SECTION:
signsinc.com.au.NS  twiggy.jetlan.com.
signsinc.com.au.NS  woody.jetlan.com.
signsinc.com.au.NS  mrt.jetlan.com.

malz@Woody:~$ for mx in $(dig +short -t mx $domain | sort -n | awk
'{print $2}')
> do
>   dig +noall +comment +ans +auth +nocl +nottl -t a "$mx"
>   dig +noall +comment +ans +auth +nocl +nottl -t  "$mx"
>   dig +noall +comment +ans +auth +nocl +nottl -t tlsa "_25._tcp.$mx"
> done
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37823
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; ANSWER SECTION:
access.signsinc.com.au. A   150.101.252.86

;; AUTHORITY SECTION:
signsinc.com.au.NS  woody.jetlan.com.
signsinc.com.au.NS  twiggy.jetlan.com.
signsinc.com.au.NS  mrt.jetlan.com.

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42772
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; AUTHORITY SECTION:
signsinc.com.au.SOA twiggy.jetlan.com.
postmaster.signsinc.com.au. 2017101602 12000 120 1209600 3600

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10350
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; ANSWER SECTION:
_25._tcp.access.signsinc.com.au. TLSA 3 1 1
EC3FED1F09D91F899A4FA41D35A2A052CD79CBDCA1F8C7A4D72FED10 61CDB9B6

;; AUTHORITY SECTION:
signsinc.com.au.NS  twiggy.jetlan.com.
signsinc.com.au.NS  mrt.jetlan.com.
signsinc.com.au.NS  woody.jetlan.com.

Re: Question regarding Postfix virtual domains and SPF

[Dominic Raferd]

On 17 October 2017 at 03:40, Viktor Dukhovni 
wrote:

> On Mon, Oct 16, 2017 at 10:05:07PM -0400, J Doe wrote:
>
> > 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) ?
>
> This requires SRS, and fairly effective anti-spam filters.  Much
> simpler to not support forwarding.
>

​or just don't worry about it
​

>
> > 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 ?
>
> When the sending domain has both SPF and DKIM, you may be fine, as
> Google should be able to figure out that the message is a real
> hotmail message relayed through your system.  However, much depends
> on the details of the upstream DKIM signature and how it is processed
> by Gmail.
>
> Domains that only publish SPF pose a more significant issue.
>

With DMARC, either an SPF pass or a DKIM pass will result in overall pass
(subject to alignment). If there is no DMARC, or DMARC p=none, neither SPF
nor DKIM failure should lead to rejection by Gmail. With DMARC
p=quarantine, Gmail puts an email that fails SPF and DKIM into spam.

So it is only really an issue if the sender domain has DMARC p=reject
policy and uses SPF without DKIM​, but in my experience (with almost
identical setup to OP) this is very rare.

Also, as Viktor's reply hints, there can be edge cases where an incoming
mail passes DKIM at our server but fails DKIM at Gmail - again these are
very rare (I am aware of one domain - with DMARC p=reject policy - some of
whose marketing emails, but nothing important, fall into this category).
Why this happens I don't know, presumably as Viktor says there is some
difference between opendkim and Gmail's dkim implementation.

For forwarding to Gmail I recommend opendmarc (as well as opendkim) on your
server, this can block some 'bad' incoming emails before they get sent on
to Gmail and damage your server's reputation.  And decent spam filtering -
I use lots of rbls as well as amavis-newd (which uses spamassassin but with
bayesian tests disabled because there can be no ham/spam learning).

Re: posttls-finger / DANE failure

[Viktor Dukhovni]

On Tue, Oct 17, 2017 at 01:56:39PM +1030, Mal wrote:

> This MTA is a dual stack postfix machine, which also has a dual stack
> resolver running.

Not clear how this is relevant...

> When testing DANE to a remove IPv4 only MTA, I see an attempt to lookup
> a non-existent  record by posttls-finger.

The only way to find out they don't exist is to ask.

> The remote site has only
> IPv4 records in the zone, except for the zone NS records, which come
> from dual stack revolvers (which are auth).

Still not clear how this is relevant.

> me@mta:/#posttls-finger -v -c -l dane -P/etc/ssl/certs domain1.com.au
> [ ... unnecessary verbose output elided ... ]
> posttls-finger: no TLSA records found, resorting to "secure"

No TLSA records were found, perhaps because the "A" records were
reported insecure, or because the TLSA records don't exist.

> The (slave) resolver on this box contains the AD records for the remote
> domain.  I don't seem to have DANE issues with any other remote DANE
> enabled domains.

There's no such thing as "AD records".  And the help you can get
will be rather limited if you must obfuscate the actual target
domain.  Post the (unobfuscated) output of:

$ domain=domain1.com.au # actual domain here
$ dig +noall +comment +ans +auth +nocl +nottl -t mx "$domain."
$ for mx in $(dig +short -t mx $domain | sort -n | awk '{print $2}')
  do
dig +noall +comment +ans +auth +nocl +nottl -t a "$mx"
dig +noall +comment +ans +auth +nocl +nottl -t  "$mx"
dig +noall +comment +ans +auth +nocl +nottl -t tlsa "_25._tcp.$mx"
  done

> As a test, when I issue the same query on the actual remote MTA, he
> receives the TLSA record successfully and is able to Verify the TLS.

Probably the resolver there behaves differently.  Post the
(unobfuscated) output of the above commands when executed there.


> Any thoughts as to why posttls-finger / postfix are seeking a
> non-existent  record ?

Wrong question.

-- 
Viktor.

Re: header_checks, filtering and loops

[Mickael DEQUIDT]

Le 16/10/2017 à 19:07, Noel Jones a écrit :


To use as an advanced content filter, your prog must be able to talk
SMTP. A simple way to do this might be to use a command line SMTP
agent such as "mini_sendmail" rather than the sendmail command.
Other - and more robust - solutions would to use a more
sophisticated filter program that accepts mail over SMTP.
amavisd-new is an example of this.


Mmh, I see. Thank you very much Noel, I'm going to investigate in that 
direction.


Have a good day, everyone !

--
Mickaël DEQUIDT
IFREMER - Service IMN/IDM/RIC
Centre Ifremer Bretagne - ZI de la pointe du diable
CS 10070 - 29280 Plouzané
Tel : +33 (0)2 98 22 46 04 - Fax : +33 (0)2 98 22 46 47



smime.p7s
Description: Signature cryptographique S/MIME