Re: Request for feedback on SMTPD restrictions

[Dominic Raferd]

On 23 January 2018 at 16:55, Noel Jones  wrote:
> On 1/23/2018 1:06 AM, Dominic Raferd wrote:
>> On 23 January 2018 at 04:20, Noel Jones > <mailto:njo...@megan.vbhcs.org>> wrote:
>>
>> Strong spam indicators for the HELO are
>> (note: this is for mail coming from the internet. Authenticated
>> submission mail or legit mail from devices on your network might
>> break any of these)
>> - a dynamic hostname (eg. 89-73-46-234.dynamic.chello.pl
>> <http://89-73-46-234.dynamic.chello.pl>, which
>> resolves just fine)
>> ...
>>
>>
>> Is there a method (regex?) for reliably identifying dynamic ip
>> addresses? Take for instance 199-127-103-235.static.avestadns.com
>> <http://199-127-103-235.static.avestadns.com> - it looks dynamic to
>> me but it says it is static. Is it best/safest to rely on
>> '\.dynamic\.' occurring in the name?
>
>
> There is no simple regexp, but there is the fqrdns.pcre project. The
> project is a large hand-maintained list of dynamic hostnames with a
> goal of zero false positives.  It's not perfect, but it's useful and
> safe for general use.
>
> https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre

Thanks Noel I have added that to my recipe (but modified the plus and
max formulae to hold rather than reject mails).

Re: Request for feedback on SMTPD restrictions

[Dominic Raferd]

On 23 January 2018 at 16:12, Andrew Sullivan  wrote:
> On Tue, Jan 23, 2018 at 10:50:24AM -0500, Kris Deugau wrote:
>>
>> There is no One True Standard, and even within the more common conventions
>> there are quite a few variations.
>
> And even if people came up with a standard, the operator could lie.
> After all, it's just DNS.  There are no DNS Police to come and tell
> you that you are using names wrong, or revoke your Internet license if
> you do so.

OK points taken thanks. Corollary: an outgoing mailserver needs an
rDNS that *indicates* a static ip - regardless of whether the ip is
actually static or dynamic. Because plenty of real-world mailservers
do block or severely limit mail from 'dynamic IPs' (e.g. gmail) but
they can base this only on a 'best guess'.

Re: Request for feedback on SMTPD restrictions

[Dominic Raferd]

On 23 January 2018 at 04:20, Noel Jones  wrote:

> Strong spam indicators for the HELO are
> (note: this is for mail coming from the internet. Authenticated
> submission mail or legit mail from devices on your network might
> break any of these)
> - a dynamic hostname (eg. 89-73-46-234.dynamic.chello.pl, which
> resolves just fine)
> ​...
>

​Is there a method (regex?) for reliably identifying dynamic ip addresses?​
Take for instance 199-127-103-235.static.avestadns.com - it looks dynamic
to me but it says it is static. Is it best/safest to rely on '\.dynamic\.'
occurring in the name?

Re: Postfix using all CPU after nightly mail submission

[Dominic Raferd]

On 19 January 2018 at 16:02, Viktor Dukhovni  wrote:
>
>
>> On Jan 19, 2018, at 10:58 AM, Dominic Raferd  wrote:
>>
>>> The pipes to "sort" should not be needed.  The output of "postconf" is 
>>> pre-sorted.
>>
>> yes I thought that - but without piping through sort I see:
>> $ comm -1 -2 <(postconf -n) <(postconf -d)
>> comm: file 2 is not in sorted order
>> comm: file 1 is not in sorted order
>
> Perhaps your locale sorts "_" the output differently than the C locale.
> Does the issue go away with:
>
> export LC_COLLATE=C

Ah yes it does. On my system LC_COLLATE is normally undefined. This
avoids the unwanted messages:

LC_COLLATE=C comm -1 -2 <(postconf -n) <(postconf -d)

Re: Postfix using all CPU after nightly mail submission

[Dominic Raferd]

On 19 January 2018 at 15:55, Viktor Dukhovni  wrote:
>
>
>> On Jan 19, 2018, at 10:46 AM, Dominic Raferd  wrote:
>>
>> Here's a way to check for explicit settings in main.cf that are
>> actually defaults and so could be removed (works under bash):
>>
>> comm -1 -2 <(postconf -n|sort) <(postconf -d|sort)
>
> The pipes to "sort" should not be needed.  The output of "postconf" is 
> pre-sorted.

yes I thought that - but without piping through sort I see:
$ comm -1 -2 <(postconf -n) <(postconf -d)
comm: file 2 is not in sorted order
comm: file 1 is not in sorted order

Re: Postfix using all CPU after nightly mail submission

[Dominic Raferd]

On 19 January 2018 at 15:21, Viktor Dukhovni  wrote:
>
>
>
> > default_destination_concurrency_limit = 50
>
> This is the default, remove the setting.
>
> ...


Here's a way to check for explicit settings in main.cf that are
actually defaults and so could be removed (works under bash):

comm -1 -2 <(postconf -n|sort) <(postconf -d|sort)

Re: Hotmail spam prevention mech.

[Dominic Raferd]

> I started a conversation with my isp and ask them whole subnet's status and
> spammers in the network. Talos gave enough details about ip address in my
> subnet. They do not believe that Microsoft categorize subnets. Actually,
> their answer was quite funny. They said, "why ms want to do that ?"
>
> Now, situation turns to convincing my isp that there are enough reasons on
> Microsoft side. They want me to prove that. Obviously I should change my
> isp.

If that is impractical, get a vps and run your mailserver there.

Re: Hotmail spam prevention mech.

[Dominic Raferd]

Please do not top-post on this mailing list...

On 16 January 2018 at 11:20, jin&hitman&Barracuda  wrote:
>
> I did not realize that nonexist host names. I believe they basically ignore 
> faults when they produce them but they keep pushing us to follow their 
> requirements.
>
>
> On 16 Jan 2018 1:59 p.m., "Jim Reid"  wrote:
>
>
>
> > On 16 Jan 2018, at 10:49, jin&hitman&Barracuda  wrote:
> >
> > We are having difficulties while delivering mails to Microsoft's domains 
> > like hotmail and outlook.
>
> They appear to have a DNS problem which is causing outbound mail to fail. 
> Their SMTP servers are using non-existent hostnames when they say HELO. This 
> DNS brokenness may well be wreaking havoc for those using SPF, DKIM, etc when 
> speaking to M$ mail servers or receiving email from them.


If you continue to have problems with your emails being dropped
instead of delivered to Microsoft domains, see
http://go.microsoft.com/fwlink/?LinkID=614866. It has worked for me
and for others.

The only problems I now have are with a very few receiving mailservers
that use TRUSTManager, possibly because they are not updating their
records. I haven't found a proper solution as this software seems to
be used by organisations that are neither big enough nor small enough
to care. My workaround is to use relaying (specified in transport
file) once I have identified a domain with this problem.

Re: Whitelist some clients from helo restrictions

[Dominic Raferd]

On 11 January 2018 at 10:15, MRob  wrote:
> I use reject_unknown_helo_hostname even though it rejects legitimate mail,
> it also catches a reasonable amount of bad things.
>
> I want to whitelist some clients of course. I thought it should be easy:
>
> /etc/postfix/main.cf
> smtpd_helo_restrictions =
>  reject_invalid_helo_hostname
>  reject_non_fqdn_helo_hostname
>  reject_unknown_helo_hostname
> smtpd_client_restrictions =
>  reject_unauth_pipelining
>  check_client_access hash:/etc/postfix/ok_clients
>
> /etc/postfix/ok_clients
> 999.999.999.999 OK
> fqdn.exmaple.com OK
>
> postmap /etc/postfix/ok_clients
>
> postmap -q 999.999.999.999 /etc/postfix/ok_clients
> OK
>
> postmap -q fqdn.exmaple.com /etc/postfix/ok_clients
> OK
>
> Yet, from this client I still get this:
> NOQUEUE: reject: RCPT from fqdn.example.com[999.999.999.999]: 450 4.7.1
> : Helo command rejected: Host not found;
>
> I test by hand and get rejected after RCPT TO (delayed restrictions as
> postfix default):
> HELO not.existing.host.name
> MAIL FROM: <...>
> RCPT TO: <...>
> **REJECTED HERE**
>
> Tried restarting postfix to be sure. What have I missed?

All restriction lists are applied: approving mail as OK in one list
only skips subsequent test in that restriction list, it does not
affect test in other lists. So add line

check_client_access hash:/etc/postfix/ok_clients

at the top of smtpd_helo_restrictions, this will then bypass the
subsequent test in this list.

You can probably remove it from smtpd_client_restrictions if you want
and in any case as the last entry in the list it does nothing as the
end of each list is equivalent to a PERMIT result.

Re: accept email if pass SPF or DKIM

[Dominic Raferd]

On 11 January 2018 at 03:24, li...@lazygranch.com  wrote:
> On Wed, 10 Jan 2018 21:59:26 -0500
>> On 1/10/2018 9:53 PM, li...@lazygranch.com wrote:

> I help with a few people I know that set up their own email to pass
> SPF and DKIM, but realistically no major corporation is going to give a
> sample of fecal matter to my opinion, presuming I could ever find the
> person in charge.
>
> Google is of the opinion that all you need is DKIM. Seems to me they
> are correct, but we have to work with whatever the sysop wants to
> implement. (Google provides SPF for their cloud servers as a means to
> get the IP space. I see hacking from that space of course, so the list
> comes in handy for blocking.)
>
> Maybe there is a way to check DKIM first, then skip the SPF check. The
> number of servers that only do SPF but not DKIM is small. I have one
> contact whose email employs neither SPF or DKIM. That is plus.net. In
> the spirit of making the world a better place, I will contact them and
> see how far I get.
>

Why reinvent the wheel? As Scott has said, this is what DMARC is for.
Google follows DMARC (although it doesn't implement it for outgoing
mails). DMARC allows senders to specify what receivers should do with
emails that purport to be from their domain (looking, critically, at
the 'From:' header) and which fail SPF *and* DKIM.

openDMARC uses headers added by openDKIM and can also look at headers
added by a local SPF checker (or perform its own SPF checking). A
perfect DKIM implementation of email for a domain makes SPF redundant
but (a) having an SPF record may improve 'reputation' and (b) a few
servers may (very unwisely IMO) reject emails based purely on SPF.
But IMO both DKIM and SPF are useless in practice without alignment,
because they test against (envelope) parameters which aren't seen by
most recipients.

I guess what you are suggesting is openDMARC with an aggressive
'policy override', where a presumed DMARC 'quarantine' (or if you
prefer 'reject') policy is implemented for all incoming emails that
have a DKIM header or which have a connected SPF policy, even if
sender's DNS has not specified such a policy in their DMARC DNS entry
or lacks a DMARC policy. On top of this you might need to whitelist
emails from mailing lists, which create problems for DMARC (or
vice-versa, depending on your point of view). This would require
patching openDMARC.

An alternative if you use Thunderbird is to get the 'DKIM Verifier'
add-on, this uses a background colo(u)r on the 'From:' header to
indicate DKIM pass/fail and, critically, alignment. Pretty cool.

Re: Microsoft silently discarding emails after recepit

[Dominic Raferd]

On 07/01/2018 05:11, Yuval Levy wrote:

On 2018-01-06 05:42 PM, Yuval Levy wrote:
I am still digesting the response received. In essence, they say that
they "have reviewed [my] IP(s) (XXX.XXX.XXX.XXX) and determined that
messages are being filtered based on the recommendations of the
SmartScreen® Filter.

On 07/01/2018 06:29, Mike Guelfi wrote:
Our alternative was always to just set relays for "poorly behaved" 
domains to go through the ISP email servers. It was slower but more 
reliable since the ISP had an artificially inflated reputation and 
more time to complain when it's email was.blocked.


Example (using sendgrid for relaying):

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

/etc/postfix/transport:
onedrive.com smtp:smtp.sendgrid.com
onedrive.co.uk smtp:smtp.sendgrid.com
hotmail.com smtp:smtp.sendgrid.com
hotmail.co.uk smtp:smtp.sendgrid.com
microsoft.com smtp:smtp.sendgrid.com
microsoft.co.uk smtp:smtp.sendgrid.com
live.co.uk smtp:smtp.sendgrid.com
live.com smtp:smtp.sendgrid.com
outlook.com smtp:smtp.sendgrid.com
msn.com smtp:smtp.sendgrid.com

Otherwise, the formatting of your DKIM record in DNS seems weird (try: 
dig +short 201605sfinacom._domainkey.sfina.com TXT); even if technically 
valid the intermediate quotes may be influencing 'SmartScreen'.

Re: report from google relate to failed dkim

[Dominic Raferd]

You are still top-posting please don't... See bottom for my reply...

On 29 December 2017 at 06:21, Poliman - Serwis  wrote:
> But "signing domain" and domain in "From" will never be matched. Server has
> own domain s1.domain.net. On this server are hosted few websites. These have
> another domains than the server fqdn. In report from google I see fail in
> dkim row but for IP of the server. I don't know why there is IP not fqdn.
>
> 2017-12-28 8:44 GMT+01:00 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).

There is no connection between ip/fqdn of the server and the signing
domain for DKIM - see man opendkim. You set all the domains for which
you want emails signed rather than verified in the 'Domain' setting in
/etc/opendkim.conf e.g.

Domain mydomain1.tld,mydomain2.tld,mydomain3.tld

Use KeyFile to give the location of the file containing the private
key to be used with all domains - and the matching public key must be
published in their DNS.

If you want to have different keys for different domains, use
KeyTable/SigningTable rather than Domain/KeyFile - I haven't tried
this. Refer to man opendkim.conf for more information.

(Apologies to anyone who feels that the postfix mailing list is not
the appropriate place to try to answer (or ask) these questions, there
doesn't seem to be an opendkim mailing list...)

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

[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

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

Re: Temporarily stop mail delivery

[Dominic Raferd]

On 26 December 2017 at 11:02, Neil Sotheby  wrote:
>
> That's a good idea but would it stop the acceptance of new incoming messages?
> ...

An expert can answer, but it would be bizarre behaviour if true. I
rather assume that postfix continues to accept incoming mails, and
queues any that are destined for the locked local file until postlock
releases its exclusive lock.

Re: Temporarily stop mail delivery

[Dominic Raferd]

On 25/12/2017 10:14, Black Sheep wrote:
Is there a simple way to temporarily stop postfix delivering mail into 
the /var/vmail mail boxes, instead queueing them up? The purpose being 
to get a clean backup of /var/vmail without stopping receipt of mail 
from the internet. Then restart mail delivery so the queue is emptied 
into the appropriate local mail boxes?
Backing up each file via postlock works well with mbox-style mail boxes, 
I don't know if it is practical with maildir. No need to modify postfix 
configuration files or to reload postfix.

Re: Requesting certificates

[Dominic Raferd]

On 22 December 2017 at 09:38, li...@lazygranch.com 
wrote:

> ​...
> From main.cf (sanitized):
> 
> # TLS
> smtpd_use_tls = yes
> ​​
> smtpd_tls_security_level = may
> smtpd_tls_auth_only = yes
> smtpd_tls_key_file = /etc/letsencrypt/live/mydomain.com/privkey.pem
> smtpd_tls_cert_file = /etc/letsencrypt/live/mydomain.com/fullchain.pem
> smtpd_tls_loglevel = 1
> smtpd_tls_received_header = yes
> #next line experimental
> ​​
> smtpd_tls_ask_ccert = yes
> smtpd_tls_session_cache_timeout = 3600s
> tls_random_source = dev:/dev/urandom


BTW, smtpd_use_tls = yes is deprecated for Postfix 2.3+: ​
​
smtpd_tls_security_level = may achieves the same thing.

Re: Question regarding use of amavisd-new

[Dominic Raferd]

On 14 December 2017 at 00:13, Maarten  wrote:

>  Where can I find documentation on all the settings of  the amavis-new
> configuration file. The only documentation I can find is about how to
> set it up with postfix in README.postfix. There are some comments in
> the configuration file, but not clear enough for me to understand what
> each setting does. Since I don't quite understand how amvisd-new works
> it would be useful to know what each setting does. That way it will be
> easier to migrate my settings over to  amavisd-new as much as it is
> possible.


amavisd-new home is https://www.ijs.si/software/amavisd/

​I suggest you look for file amavisd.conf-default or you can download the
latest version from
https://www.ijs.si/software/amavisd/amavisd.conf-default.​ [Occasionally
the defaults given in this file may be overridden in the build, for
instance amavisd.conf-default states that default $MYHOME = '/var/amavis'
but in Ubuntu's package of amavisd-new $HOME has default value
/var/lib/amavis - probably Debian is the same.]

Re: SV: Good solution for antivirus

[Dominic Raferd]

On 1 December 2017 at 13:54, K F  wrote:
> Btw. we're using PRTG to monitor how the system fares, so far I can monitor
> most things, but how about ClamAV? Anybody that has an idea on how monitor
> the milter?

You can check clamav's log file(s) thus:
grep -a "clamd.*FOUND$" /path/to/logfile

Re: SV: Good solution for antivirus

[Dominic Raferd]

On 30 November 2017 at 16:28, Gary  wrote:
>
> FWIW
> ...
>
> From: fribse2...@yahoo.dk
> Ok, it looks like there is a clamav-milter available in the EPEL, that seems 
> to be the simplest solution.
> So I've installed clamav-milter-systemd clamav-scanner-systemd

If you use clamav you should add the Sanesecurity
(http://sanesecurity.com/) signatures - in my experience these are
responsible for all clamav's real-world virus trapping. See the readme
at https://github.com/extremeshok/clamav-unofficial-sigs/tree/dev.

Re: Kill off one user's active sessions

[Dominic Raferd]

On 22 November 2017 at 14:31, Vegard Svanberg  wrote:
> We have a few scripts in place to handle (outgoing) spam outbreaks.
>
> This works well, but we struggle a bit with one scenario where the
> username and password are in the wild, and the spammer connects to the
> email server and sends multiple emails through the same connection.
>
> Because even if we lock the account, the session is still active so they
> can spam until the connection is terminated.
>
> The same scenario occurs if a botnet has set up multiple connections,
> but the server is laggy or whatever so they've authenticated, but
> haven't gotten to the "DATA" part of the SMTP dialogue yet (BTW: some
> spambots appear to exhibit speculative behaviour here - as if they do
> this on purpose).
>
> So... what's the recommended approach here?
>
> Is there an easy way to tear down specific (by a particular user)
> connections?

Maybe you could create a fail2ban jail based on frequency of
repetition of log entries of the multiple outgoing emails? Obviously
you would have to find some reliable way to distinguish between the
log entries generated by a spammer's mails and a genuine user's (which
might be tricky if your genuine users might also send a lot of emails
in a short space of time). Normally fail2ban is used for temporary IP
blocking via iptables (but other actions are possible).

Someone had a similar problem here:
https://www.howtoforge.com/community/threads/postfix-dos-spam-attack.61196/

Re: Rejecting mail dorm a domain to specific user

[Dominic Raferd]

On 22 November 2017 at 12:52, @lbutlr  wrote:
> Is it possible to reject a mail from a specific domain to a specific user?
>
> Obviously, there are other ways to deal with this, but I have a case where 
> I’d prefer to reject the mail before it is received but I do not want to 
> block the domain for other users.

Untested concept only, so corrections/improvement are welcome. Use a
restriction list that is not used otherwise (here:
smtpd_client_restrictions):

/etc/postfix/main.cf:

# using smtpd_client_restrictions you must have
#   smtpd_delay_reject = yes (the default) so it is evaluated
#   at the time of the RCPT TO command, otherwise
#   check_sender_access and check_recipient_access won't work
smtpd_delay_reject = yes
smtpd_client_restrictions =
  check_sender_access pcre:/etc/postfix/sender_access.pcre
  check_recipient_access hash:/etc/postfix/recipient_access
  permit


/etc/postfix/sender_access.pcre:
/^permit...@sender.tld$/ DUNNO
/.*/ OK

/etc/postfix/recipient_access:
permit...@recipient.tld REJECT

Re: Rewrite the To: header?

[Dominic Raferd]

On 19 November 2017 at 16:36, Jack Bates  wrote:
>
> Is there a feature I can use to rewrite the To: header, of "virtual alias 
> domain" mail, with the result of the following lookup, *after* smtpd_milters 
> are applied?
>
> SELECT 'b...@example.com' FROM my_table WHERE sender = '%s'
>
> Or do I need to use a milter of my own for this?
>
> recipient_canonical_maps and recipient_canonical_classes seem pretty close! I 
> can exclude the From: header and the envelope_recipient from being rewritten, 
> but they're applied *before* smtpd_milters. And I haven't thought carefully 
> about how to limit them to virtual alias domain mail.
>
> My specific situation is that I'm using the OpenDKIM milter to verify mail, 
> so that needs to happen before I rewrite the To: header.


Just checking that you really want/need to rewrite the To: header and
not just the actual recipient? virtual_alias_(domains|maps) can do the
latter. Otherwise, maybe smtp_generic_maps.

Re: Backup mx relay got rejected due to SPF

[Dominic Raferd]

On 18 November 2017 at 14:46, Benny Pedersen  wrote:

> Dominic Raferd skrev den 2017-11-18 09:55:
>
> I conclude that, for me, blocking on the basis of spf would have a
>> negligible effect on my incoming spam and an unacceptable level of
>> false positives. Obviously other people's mileage might vary.
>>
>
> and opendmarc have spf bugs :/
>

​opendmarc 1.3.2 can use libspf2 which I think is reliable; but I use
python-policyd-spf to provide spf data for opendmarc.

Re: Backup mx relay got rejected due to SPF

[Dominic Raferd]

This thread has prompted me to look at my opendmarc log records - these
cover all incoming mails to my mailservers, not only those from senders
that use dmarc. Helpfully, the logs show the pure spf test results; these
actually come from policyd-spf which I run with 'defaultSeedOnly = 1' so it
merely adds headers to be read by opendmarc and does not actually block
anything.

I find that there are very few spf 'hard' fails [code 7] (34 out of >45000)
and about half of these are clearly from legitimate senders with
misconfigured spf. There is a higher level of softfails [code 2] (252) of
which the vast majority are clearly from legitimate senders.

I conclude that, for me, blocking on the basis of spf would have a
negligible effect on my incoming spam and an unacceptable level of false
positives. Obviously other people's mileage might vary.

Re: bounce notify class

[Dominic Raferd]

On 13 November 2017 at 01:09, Wietse Venema  wrote:

> Dominic Raferd:
> > ?I am deluged with messages in the postmaster mailbox reporting failed
> > smtpd transactions for spammers trying to send to non-existent recipients
> > on our domain?, which postfix quite rightly rejects (i.e. not listed in
> > virtual_alias_maps). These are smtpd transaction reports not bounces, but
> > they are sent automatically to $bounce_notice_recipient as part of the
> > bounce error class. This is 'by design';
>
> Incorrect. By default, Postfix does not send postaster notification
> for rejected mail.
>
> The default setting is:
>
> notify_classes = resource, software
>
> You have added 'bounce' to that list. It you don't want such email,
> then don't set notify_classes to send such email.


Thanks Wietse, that takes me back to my first post in this thread: 'I want
to turn off the the bounce error class to reduce clutter in my postmaster
mailbox, but don't want to miss something important.' I now infer from its
default setting that there is nothing important generated by the bounce
error class.

Re: bounce notify class

[Dominic Raferd]

On 12 November 2017 at 10:57, Postmaster  wrote:

> You should neither ignore your Postfix bounces (called Local/synchronous
> bounces) nor generated by other providers (called Remote/ Asynchronous
> bounces). Both should be processed correctly and not be retried if its
> related to mailbox/user does not exist. It is one of the important factor
> that affects your email deliverability and IPs/ Domains reputation.
>
> Hope it helps.
>
> Thanks.
>
> On Wed, Nov 8, 2017 at 3:05 PM, Dominic Raferd 
> wrote:
>
>>
>>
>> On 8 November 2017 at 08:34, Alex JOST  wrote:
>>
>>> Am 07.11.2017 um 14:54 schrieb Dominic Raferd:
>>>
>>>> I want to turn off the the bounce error class to reduce clutter in my
>>>> postmaster mailbox, but don't want to miss something important.
>>>>
>>>> The bounce error class is defined (
>>>> http://www.postfix.org/postconf.5.html#notify_classes) as: 'Send the
>>>> postmaster copies of the headers of bounced mail, and send transcripts
>>>> of
>>>> SMTP sessions when Postfix rejects mail.'
>>>>
>>>> I understand the second of these (and receive many of them, which I
>>>> don't
>>>> want) but not the first (and don't seem to receive any).
>>>>
>>>> What are 'copies of the headers of bounced mail' - would this be mail
>>>> that
>>>> has been bounced by Postfix (not interesting to me) or mail bounced by
>>>> an
>>>> onward mailserver (interesting to me - but maybe this is covered by the
>>>> 2bounce error class)?
>>>>
>>>>
>>> No, only bounces of outgoing mails. For us that's mainly bounces because
>>> of misspelled e-mail addresses (connection timeout and mailbox unavailable).
>>
>>
>> ​Thanks Alex. With that info I have worked out (using a subtle difference
>> in the 'from' address in my configuration) which error messages are due to
>> '2bounce' error class and which ones are from other classes (most likely
>> 'bounce').
>>
>> IMO it would be helpful if Postfix added a header to any mail triggered
>> by an error identifying what error class(es) triggered it, or would this
>> break some RFC?
>>
>
>
>
​I am deluged with messages in the postmaster mailbox reporting failed
smtpd transactions for spammers trying to send to non-existent recipients
on our domain​, which postfix quite rightly rejects (i.e. not listed in
virtual_alias_maps). These are smtpd transaction reports not bounces, but
they are sent automatically to $bounce_notice_recipient as part of the
bounce error class. This is 'by design'; however I don't want to see these
(why would I? and the info is in the log anyway), while I do want to see
other messages generated as part of the bounce error class, since these can
be significant. It is surprising to me that there is no way of turning off
one without turning off the other. (My workaround is a script that
automatically marks the transaction reports as 'read'.)

Re: Helo rejected

[Dominic Raferd]

On 10 November 2017 at 14:08, Enrico Morelli  wrote:

> my user don't receive mail from a real sender cause our mail server
> reject the Helo command:
>
> NOQUEUE: reject: RCPT from rrcs-70-60-37-220.central.biz.rr.com[70.60.37.220]:
> 450 4.7.1
> : Helo command rejected: Host not found;
> from= to= proto=ESMTP
> helo=
> Nov  8 17:55:46 genio postfix/smtpd[3667]: disconnect from
> rrcs-70-60-37-220.central.biz.rr.com[70.60.37.220] ehlo=1 mail=1
> rcpt=0/1 rset=1 quit=1 commands=4/5
>
> Is there a way to receive these mails?


​You may be using this setting ​in one of your restriction lists:
reject_unknown_helo_hostname. Remove this and you should be ok. I think
there is not much point worrying about helo hostnames, they are easy to
fake in any case. Better to focus on client reverse hostnames.

Re: bounce notify class

[Dominic Raferd]

On 8 November 2017 at 08:34, Alex JOST  wrote:

> Am 07.11.2017 um 14:54 schrieb Dominic Raferd:
>
>> I want to turn off the the bounce error class to reduce clutter in my
>> postmaster mailbox, but don't want to miss something important.
>>
>> The bounce error class is defined (
>> http://www.postfix.org/postconf.5.html#notify_classes) as: 'Send the
>> postmaster copies of the headers of bounced mail, and send transcripts of
>> SMTP sessions when Postfix rejects mail.'
>>
>> I understand the second of these (and receive many of them, which I don't
>> want) but not the first (and don't seem to receive any).
>>
>> What are 'copies of the headers of bounced mail' - would this be mail that
>> has been bounced by Postfix (not interesting to me) or mail bounced by an
>> onward mailserver (interesting to me - but maybe this is covered by the
>> 2bounce error class)?
>>
>>
> No, only bounces of outgoing mails. For us that's mainly bounces because
> of misspelled e-mail addresses (connection timeout and mailbox unavailable).


​Thanks Alex. With that info I have worked out (using a subtle difference
in the 'from' address in my configuration) which error messages are due to
'2bounce' error class and which ones are from other classes (most likely
'bounce').

IMO it would be helpful if Postfix added a header to any mail triggered by
an error identifying what error class(es) triggered it, or would this break
some RFC?

bounce notify class

[Dominic Raferd]

I want to turn off the the bounce error class to reduce clutter in my
postmaster mailbox, but don't want to miss something important.

The bounce error class is defined (
http://www.postfix.org/postconf.5.html#notify_classes) as: 'Send the
postmaster copies of the headers of bounced mail, and send transcripts of
SMTP sessions when Postfix rejects mail.'

I understand the second of these (and receive many of them, which I don't
want) but not the first (and don't seem to receive any).

What are 'copies of the headers of bounced mail' - would this be mail that
has been bounced by Postfix (not interesting to me) or mail bounced by an
onward mailserver (interesting to me - but maybe this is covered by the
2bounce error class)?

Re: bloc domains with all variants of tld

[Dominic Raferd]

On 6 November 2017 at 15:08, Viktor Dukhovni 
wrote:

>
>
> > On Nov 6, 2017, at 6:15 AM, Dominic Raferd 
> wrote:
> >
> > ​So say use pcre and study http://www.postfix.org/pcre_table.5.html.
> Example (untested):
> >
> > /@example\..*​$/ REJECT
>
> This will block "example" at more than just the 2LD level.
>

​True, but to block say 'any...@example.co.uk' you need to block at more
than 2LD level.​

Re: bloc domains with all variants of tld

[Dominic Raferd]

On 6 November 2017 at 10:43, wodel youchi  wrote:

> Hi,
>
> both are supported pcre and regexp.
>
>
>
> 2017-11-06 11:07 GMT+01:00 Ralph Seichter :
>
>> On 06.11.2017 10:26, wodel youchi wrote:
>>
>> > We need to bloc some incoming emails from certain domains.
>> > How to write rules to bloc a domain with all its variant of tld?
>>
>> Access tables can support regexp or pcre, if your Postfix has been
>> compiled that way. The postconf -m command will show you which map
>> types are supported.
>>
>
​So say use pcre and study http://www.postfix.org/pcre_table.5.html.
Example (untested):

/@example\..*​$/ REJECT

Re: Emails are not passed to Amavis after redirection by header check

[Dominic Raferd]

On 3 November 2017 at 11:18, ruttentuttels  wrote:

> ​...​
>
> The first email received has the subject of the header check filter and is
> forwarded to the spam account.
> The second email has a subject which does not match the filter and is
> delivered to Amavis.
>
> Question is why the redirected email to the spam box is NOT passing Amavis.

​

​I notice at http://www.postfix.org/FILTER_README.html that it is stated
under ​'Limitations':
- If a message triggers more than one filter action, only the last one
takes effect.
- FILTER actions from smtpd access maps and header/body_checks take
precedence over filters specified with the main.cf content_filter parameter.

So I think you cannot apply a header_checks filter and then a
content_filter as you are trying. A way round it might be to apply the
content filtering from within one of the restriction lists - see
https://git.ispconfig.org/ispconfig/ispconfig3/issues/833?

Re: unable to send email to hotmail.com domain

[Dominic Raferd]

>
>
> 2017-10-26 14:33 GMT+02:00 Dominic Raferd :
>
>>
>>>> You could use a mail relaying service such as Sendgrid.
>>>> ​..
>>>>
>>> ​​
>
> On 26 October 2017 at 13:37, Poliman - Serwis  wrote:
>
>> Thank you Dominic for answer. It's kind of workaround, am I right?
>>
>
​Yes, and unless you change your server's ip it is likely the only way to
make it work. I have this problem with one mail server and I use this
approach.​

Re: unable to send email to hotmail.com domain

[Dominic Raferd]

On 26 October 2017 at 12:28, Victoriano Giralt  wrote:

> On 26/10/17 13:14, Dominic Raferd wrote:
> > On 26 Oct 2017 6:34 am, "Poliman - Serwis"  >> I know that MS has own black list but why they block me. Domain
> >> which I use to send confirmation links is clear (checked in), ip
> >> address of my server also is clear.
> >>
> >
> > You could use a mail relaying service such as Sendgrid. Have a transport
> > file set to relay only emails to Microsoft domains through this service.
>
> And accept extortion for doing something that has an IETF sanctioned
> protocol that is not working because of the wrongdoings a a monopolistic
> entity.


Not really extortion because Sendgrid, for example, offer free accounts
sending up to 12K mails / month.​

Re: unable to send email to hotmail.com domain

[Dominic Raferd]

On 26 October 2017 at 12:16, Poliman - Serwis  wrote:

> These emails are filtered somehow that they can reach MS domains?
>
> 2017-10-26 13:14 GMT+02:00 Dominic Raferd :
>
>>
>>
>> On 26 Oct 2017 6:34 am, "Poliman - Serwis"  wrote:
>>
>> I have strange irritating problem. When I send emails from my server to
>> any email address to any domain they reach the target without any problem.
>> But when I try send to address in "hotmail.com" I got bounce:
>> : host
>> hotmail-com.olc.protection.outlook.com[104.47.40.33] said: 550 5.7.1
>> Unfortunately, messages from [ip_of_my_server] weren't sent. Please
>> contact
>> your Internet service provider since part of their network is on our
>> block
>> list (AS3140). You can also refer your provider to
>> http://mail.live.com/mail/troubleshooting.aspx#errors.
>> [CO1NAM03FT055.eop-NAM03.prod.protection.outlook.com] (in reply to
>> MAIL
>> FROM command)
>>
>> I know that MS has own black list but why they block me. Domain which I
>> use to send confirmation links is clear (checked in), ip address of my
>> server also is clear.
>>
>>
>> You could use a mail relaying service such as Sendgrid. Have a transport
>> file set to relay only emails to Microsoft domains through this service.
>>
>
First, get your Sendgrid (or whatever) account set up and have it
configured in sasl_passwd. Then, for example:

/etc/postfix/main.cf:

transport_maps = hash:/etc/postfix/transport​


/etc/postfix/transport:
onedrive.com smtp:smtp.sendgrid.com
onedrive.co.uk smtp:smtp.sendgrid.com
hotmail.com smtp:smtp.sendgrid.com
hotmail.co.uk smtp:smtp.sendgrid.com
microsoft.com smtp:smtp.sendgrid.com
microsoft.co.uk smtp:smtp.sendgrid.com
live.co.uk smtp:smtp.sendgrid.com
live.com smtp:smtp.sendgrid.com
outlook.com smtp:smtp.sendgrid.com
msn.com smtp:smtp.sendgrid.com

and do:
postmap /etc/postfix/transport

Re: unable to send email to hotmail.com domain

[Dominic Raferd]

On 26 Oct 2017 6:34 am, "Poliman - Serwis"  wrote:

I have strange irritating problem. When I send emails from my server to any
email address to any domain they reach the target without any problem. But
when I try send to address in "hotmail.com" I got bounce:
: host
hotmail-com.olc.protection.outlook.com[104.47.40.33] said: 550 5.7.1
Unfortunately, messages from [ip_of_my_server] weren't sent. Please
contact
your Internet service provider since part of their network is on our
block
list (AS3140). You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors.
[CO1NAM03FT055.eop-NAM03.prod.protection.outlook.com] (in reply to MAIL
FROM command)

I know that MS has own black list but why they block me. Domain which I use
to send confirmation links is clear (checked in), ip address of my server
also is clear.


You could use a mail relaying service such as Sendgrid. Have a transport
file set to relay only emails to Microsoft domains through this service.

Re: easy DKIM question, at least i think it is...

[Dominic Raferd]

On 20 October 2017 at 18:28, Fazzina, Angelo 
wrote:

> Hi, i have a small DKIM question.   config files are at bottom of email.
> I got it working but don't understand why ?
>
> The one change i made to get it to work was add
> 137.99.0.0/16 to the TrustedHosts file.
>
> So  tests with from of  x...@appmail.uconn.edu and x...@uconn.edu are getting
> signed and I see it in the Postfix logs.
>
>
> My question:
> my prod servers(3 of them)  smtp.uconn.edu allow authenticated users to
> send over 465 and 587.
> So they could come from any IP address in the world.
> I assume all users are using a from address of x...@uconn.edu or
> x...@yyy.uconn.edu.
> Is it possible to get emails signed with DKIM ?
>
>
>
> These are the 3 files i configured
> SigningTable =
> *@appmail.uconn.edu dkim1._domainkey.mta4.uits.uconn.edu
> *@uconn.edu dkim1._domainkey.mta4.uits.uconn.edu
> *@uits.uconn.edu dkim1._domainkey.mta4.uits.uconn.edu
>
> KeyTable =
> dkim1._domainkey.mta4.uits.uconn.edu mta4.uits.uconn.edu:dkim1:/
> etc/opendkim/keys/uconn/dkim1.private
>
> TrustedHosts =
> 127.0.0.1
> 137.99.0.0/16
> ::1
>
> This is the opendkim.conf file =
>
> PidFile /var/run/opendkim/opendkim.pid
> Modesv
> Syslog  yes
> SyslogSuccess   yes
> LogWhy  yes
> UserID  opendkim:opendkim
> Socket  inet:8891@localhost
> Umask   002
> SendReports yes
> ReportAddress   "UITS-SSG OpenDKIM" 
> SoftwareHeader  yes
> Canonicalizationrelaxed/simple
> Selectordkim1
> MinimumKeyBits  1024
> KeyTable/etc/opendkim/KeyTable
> SigningTablerefile:/etc/opendkim/SigningTable
> ExternalIgnoreList  refile:/etc/opendkim/TrustedHosts
> InternalHosts   refile:/etc/opendkim/TrustedHosts


Referring to man opendkim.conf, under 'Mode' I see you are using mode (b)
in which case I think 'Selector' should not be defined. (I use mode (a),
which is rather simpler.) Try removing 'Selector' from opendkim.conf and
see what happens.

Presuming that your setup already blocks unauthenticated senders purporting
to be from @your_domain, I don't think you should need or have to rely on
InternalHosts or ExternalIgnoreList. Emails that need signing, and do not
need testing for an existing valid signature, should be identified solely
from SigningTable.​ There shouldn't be any that don't need signing *and*
don't need testing for a valid signature (i.e. that need to be specified in
ExternalIgnoreList) except perhaps for an intranet mail system - emails
must either be from the outside world and require testing for dkim, or be
from a recognised sender using one of your domains, and require a signature
to be added. Similarly there shouldn't be any, even from the local system,
that are not from one of your domains and do need a signature adding (i.e.
that need to be specified in InternalHosts).

If rewriting any (local) sender addresses be sure to use postfix's
canonical_maps and not smtp_generic_maps so that the change precedes the
adding of the signature by opendkim.

Re: Block IP rcpt-to or block MX

[Dominic Raferd]

On 20 October 2017 at 14:50, Emanuel  wrote:

> Quota: *Obvs you need to hash the transport file and then reload postfix.
> This transport file can easily be extended to cover similar cases.*
>
> how to make this?
>
​
postmap /etc/postfix/transport
postfix reload​

Re: Block IP rcpt-to or block MX

[Dominic Raferd]

On 20 October 2017 at 14:21, Emanuel  wrote:

> Hello,
>
> Is it possible to create a list where the IP of certain recipients can be
> blocked?
>
> Here and example:
>
> Oct 19 10:15:09 smtp01 postfix/smtpd[11048]: 5C28C20018459:
> client=myserver[172.17.111.242]
> Oct 19 10:15:09 smtp01 postfix/cleanup[6836]: 5C28C20018459: message-id=
> <59e8a0ca77...@domain.com> <59e8a0ca77...@domain.com>
> Oct 19 10:15:09 smtp01 postfix/qmgr[3054]: 5C28C20018459: from=
>  , size=16981, nrcpt=1 (queue active)
> Oct 19 10:15:25 smtp01 smht-101-41/smtp[7698]: 5C28C20018459: to=
>  , 
> relay=mail.h-email.net[198.133.159.122]:25,
> delay=16, delays=0.15/0/9.2/6.3, dsn=2.0.0, status=sent (250 Queued!)
> Oct 19 10:15:25 smtp01 postfix/qmgr[3054]: 5C28C20018459: removed
>
> Our users incorrectly type the domain name of the recipient.
>
> *hotmial.com  ==> hotmail.com *
>
> My idea is block the MX or IP ==> mail.h-email.net - 198.133.159.122
>

​A better idea is to block the sending by recipient domain, with a suitable
warning:

/etc/postfixmain.cf:

transport_maps = hash:/etc/postfix/transport


/etc/postfix/transport:
hotmial.com error:5.1.2 maybe you mean hotmail.com
hotmal.com error:5.1.2 maybe you mean hotmail.com
hoitmail.com error:5.1.2 maybe you mean hotmail.com
homail.com error:5.1.2 maybe you mean hotmail.com
hotrmail.com error:5.1.2 maybe you mean hotmail.com
hotmil.com error:5.1.2 maybe you mean hotmail.com
hotmaill.com error:5.1.2 maybe you mean hotmail.com


Obvs you need to hash the transport file and then reload postfix. This
transport file can easily be extended to cover similar cases.

Re: Tailored filter

[Dominic Raferd]

On 19 October 2017 at 10:48, Seb  wrote:

>
> ​...
> Typically, mail sent to .@ is redirected
> to .@gmail.com, the usual email address of the
> author.
>
> I've been using this for 15+ years and it's been great. Unfortunately, I'm
> losing the war against spam. In spite of careful configuration of Postfix,
> the use of Postgrey and hand-drawn blacklists, too much spam passes
> through. What my server regards as legitimate email (but is sometimes spam)
> gets resent to sites such as GMail which, in turn, tend to flag all email
> from my domain as spam, even legitimate emails. And this is starting to
> jeopardize my communication with the rest of the world.
> ​..
>

I relay successfully to Gmail with some small domains. My setup in outline
is:

   - emails from unauthenticated non-local senders are rejected unless to a
   known approved recipient
   - many external rbls (requires local DNS server [bind] with forwarding -
   but with forwarding disabled for rbl zones)
   - python-policyd-spf (adds header for review by opendmarc)
   - opendkim (tests 'incoming' emails and adds header for review by
   opendmarc, signs 'outgoing' emails)
   - opendmarc - with enforcement for 'incoming' emails
   - reject_unknown_reverse_client_hostname
   - amavisd-new - uses Spamassassin (with use_bayes 0), ClamAV (with
   Sanesecurity), razor, pyzor
   - bespoke filtering by ip, sender name, client/host name, helo name,
   headers
   - fail2ban (tweaked 'dovecot' and bespoke 'postfix-failedauth' jails)
   - relay-enforcer (bespoke, requires fail2ban and short-term local backup
   of emails)
   - permanent ip banning via ufw for repeat fail2ban or unresolved
   hostname offenders (bespoke)

​Some of this is bespoke but much of it is easily replicated. I recently
gave up using postgrey because the delayed delivery drove users mad.

I realise this doesn't answer your question, but it may suggest a different
way forward.

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

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: Blocking mail from clients who

[Dominic Raferd]

On 16 October 2017 at 11:38, Matus UHLAR - fantomas 
wrote:

> On 15.10.17 16:52, Bill Shirley wrote:
>
>> /.*@mydomain.tld/ REJECT
>>>
>>
>> The leading .* is not needed.  You should escape the period before tld
>> (\.).  You can
>> also send a message:
>> /@.*example\.com$/REJECT You are not me (40,000).
>> This works for me.  Note: I'm using pcre instead of regexp.
>>
>
> and this .* is dangerous. it denies subdomains as well as other domains
> ending as example.com - e.hg. myexample.com might be foreign domain but
> you
> will reject it.
>
> instead of regexp (or pcre) I recommend using simple checks like hash:
>
> example.com REJECT Authentication needed for this domain.
>
> you can still use regular expressions afterwards.


This regex will not deny subdomains or other domains:

/@example\.com$/ REJECT

In general hash table​ is simpler (and faster) but OP is already using
regex table so this avoids having to amend main.cf and create and hash a
new file.

Re: Blocking mail from clients who

[Dominic Raferd]

On 15 October 2017 at 17:34, Gerben Wierda  wrote:

> My main restrictions in main.cf are (on macOS Server)
>
> smtpd_client_restrictions =
> permit_mynetworks,
> permit_sasl_authenticated,
> check_client_access regexp:/Library/Server/Mail/Config/postfix/rna_rbl_
> whitelist_clients,
> reject_rbl_client zen.spamhaus.org,
> permit
> smtpd_delay_reject = yes
> smtpd_enforce_tls = no
> smtpd_helo_required = yes
> smtpd_helo_restrictions =
> permit_mynetworks,
> reject_non_fqdn_helo_hostname,
> reject_invalid_helo_hostname,
> permit
> smtpd_recipient_restrictions =
> ​​
> permit_sasl_authenticated reject_unauth_pipelining
> reject_non_fqdn_recipient permit_mynetworks reject_unauth_destination
> reject_unlisted_recipient check_client_access regexp:/Library/Server/Mail/
> Config/postfix/rna_policy_whitelist_clients check_sender_access
> regexp:/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders
> check_policy_service unix:private/policy permit
>
> Rbl and greylisting helps to filter out most spam attempts. I have to turn
> of greylisting for a few hours today, and a message came through that had
> both From: and To: set to my email address. This was accepted because I am
> the delivery agent for that domain.
>
> But an outside, non SASL-authenticated client that says it wants to
> deliver mail From my domain is illegal. Apparently, that one still gets
> through (though is generally blocked by greylisting). Anyway, is there a
> way to block that without blocking legitimate mail?
>

​You could add your domain to
/Library/Server/Mail/Config/postfix/rna_policy_whitelist_senders as a
reject:

/.*@mydomain.tld/ REJECT

Any sender purporting to be from your domain but not authenticated should
be blocked by this. Authenticated senders will not be touched by this
because they are already approved by ​permit_sasl_authenticated.

Re: Postfix mail logging stops and starts

[Dominic Raferd]

On 19 September 2017 at 08:55, Yukthi Systems 
wrote:

>
> We are facing an issue where the mail logging stops
> and starts at regular intervals without an intervention, there
> is no error and the email system keeps working, but only
> problem is we keep missing the logs between intervals
> when there is no mail logging happening, please suggest.​
>

​This is unlikely to be postfix-related. Consider:

- do other system processes continue logging while mail logging is stopped?
- how regular are the intervals without mail logging?
- is there plenty of space in the log filesystem?​ (maybe space runs out
from time to time?)
- what distro / logging software (e.g. rsyslog, syslog-ng) / init system
(e.g. systemd, Sys-V)?

Re: Letsencrypt tip

[Dominic Raferd]

On 13 September 2017 at 19:54, Viktor Dukhovni 
wrote:

>
> > On Sep 13, 2017, at 4:10 AM, Dominic Raferd 
> wrote:
> >
> > As Postfix SMTP server does not support SNI I think there is no point
> using
> > -servername option above, so the above can be shortened to:
> >
> > ​echo |
> > sudo openssl s_client -connect 127.0.0.1:587 -starttls smtp 2>/dev/null
> |
> > openssl x509 -noout -checkend 259200​
>
> There definitely good reason to avoid "sudo", which is unnecessary here.
> As for SNI, indeed not needed if the server being tested is known to be
> Postfix.
>

​Thanks for the correction and confirmation
​

>
> > I'm still unclear whether the test is against the certificate data that
> > is held within postfix or that is held within the SASL application
> > (dovecot or cyrus).
>
> Now you betray some confusion, SASL is NOT TLS and does not exchange
> certificates with the SASL client.  The application protocol that
> supports SASL may run over TLS, in which case the server and sometimes
> also the client might present X.509 certificates, but SASL could not
> possibly do that absent a "TLS" mechanism for SASL that would use
> client certificates for authentication and then TLS as the SASL
> "security layer".  AFAIK no such mechanism exists, and Postfix has no
> support for SASL "security layers" in any case.


​Indeed I was confused! So I now understand that the certificate references
in my ​/etc/dovecot/conf.d/10-ssl.conf:

ssl_cert = https://wiki.dovecot.org/SSL/DovecotConfiguration it seems that for Dovecot
(unlike Postfix) a manual reload is needed to get it to re-read these
certificates when they have changed. (All off-topic for Postfix, of course,
sorry...)

Re: Letsencrypt tip

[Dominic Raferd]

On 11 September 2017 at 17:22, Dominic Raferd 
wrote:

> On 11/09/2017 12:33, Christian Kivalo wrote:
>
>> On 2017-09-11 11:21, Dominic Raferd wrote:
>>
>>> ​Does anyone know a way to detect if the certificate currently being
>>> used by Postfix and/or Dovecot is nearing expiry (esp. in case they
>>> haven't picked up the updated letsencrypt certificate)?
>>>
>> ​...​
>>
>>
>> This example gives exit code 1 if the certificate has less than 3 days
> (259200 seconds) to expiry:
>
> ​​
> echo|sudo openssl s_client -connect 127.0.0.1:587 -starttls smtp
> -servername my.domain.tld 2>/dev/null|openssl x509 -noout -checkend 259200
>

​As postfix SMTP server does not support SNI I think there is no point
using -servername option above, so the above can be shortened to:

​
echo | sudo openssl s_client -connect 127.0.0.1:587 -starttls smtp
2>/dev/null | openssl x509 -noout -checkend 259200​

If checking a remote server, substitute 127.0.0.1 with the remote address.

I'm still unclear whether the test is against the certificate data that is
held within postfix or that is held within the SASL application (dovecot or
cyrus).

Re: How to check for upcoming certificate expiration...

[Dominic Raferd]

On 11 September 2017 at 19:25, Viktor Dukhovni 
wrote:

>
> > On Sep 11, 2017, at 5:21 AM, Dominic Raferd 
> wrote:
> >
> > Does anyone know a way to detect if the certificate currently being used
> by Postfix and/or Dovecot is nearing expiry (esp. in case they haven't
> picked up the updated letsencrypt certificate)?
>
> See below for OpenSSL 1.0.2 or later.
> ​..​
>
>
> #! /bin/bash
> ​...
>

​Thanks Viktor I am sure I will find this helpful and I love your elegant
bash coding. Can I ask a couple of dump questions?

- what do I specify for the CAfile?
- does this check against the certificates being offered both by Postfix
and Dovecot (which I use for SASL) or just one of them and if so which one?​

Re: Letsencrypt tip

[Dominic Raferd]

On 11/09/2017 12:33, Christian Kivalo wrote:

On 2017-09-11 11:21, Dominic Raferd wrote:

​Does anyone know a way to detect if the certificate currently being
used by Postfix and/or Dovecot is nearing expiry (esp. in case they
haven't picked up the updated letsencrypt certificate)?

You mean like this from the letsencrypt forum

adapted for submission on port 587 with starttls:
openssl s_client -connect yourdomain.tld:587 -starttls smtp 
-servername yourdomain.tld 2>/dev/null | openssl x509 -noout -dates


https://community.letsencrypt.org/t/it-there-a-command-to-show-how-many-days-certificate-you-have/11351/2 



Thanks to all for the great tips. This example gives exit code 1 if the 
certificate has less than 3 days (259200 seconds) to expiry:


echo|sudo openssl s_client -connect 127.0.0.1:587 -starttls smtp 
-servername my.domain.tld 2>/dev/null|openssl x509 -noout -checkend 259200

Re: Letsencrypt tip

[Dominic Raferd]

On 11 September 2017 at 11:59, Gary  wrote:

> As you know, letsencrypt certs can be automatically updated. However, you
> need to reload/restart Postfix/Dovecot to use the new cert. My email client
> insisted I had an expired cert. I couldn't download or send email.
> (Fortunately I'm on a test domain, getting ready for the Oct 1st Google
> insistence on encryption.)
>
> Letsencrypt suggests running acme on a daily basis, so just do the same
> for Postfix and Dovecot.
>

​Does anyone know a way to detect if the certificate currently being used
by Postfix and/or Dovecot is nearing expiry (esp. in case they haven't
picked up the updated letsencrypt certificate)?

Re: sender_access question

[Dominic Raferd]

On 30 August 2017 at 10:30, mbridgett  wrote:

> Hi,
>
> This is the first time I have configured sender_access blacklisting -
> although it works fine - i.e. the specific email address I have chosen to
> blacklist get's their email blocked with /var/log/messages noting it as
> "Sender address rejected:access denied".  I notice that after an hour has
> gone by- the email is attempted to be delivered again.   Maybe I have
> missed
> a subtlety here but I thought a REJECT would immediately return the message
> to the sender but that doesn't appear to be the case.
>
> I guess my question is - how many times will the message be attempted to be
> re-delivered, with my mail server rejecting it - until it will eventually
> be
> returned as undeliverable?


​With 'REJECT' action Postfix will have sent code $access_map_reject_code
(default 554) back to the sending server and so that server should not
attempt to send the same email again - see
http://www.postfix.org/access.5.html. Of course if the sending server is
badly-configured or malicious it may well ignore the code and try to resend
the email or (more likely) send similar (but technically different) emails.
There is nothing further than Postfix can do to stop this happening.

If the offending emails are all coming from the same ip you could ban this
ip with iptables / ufw. A less drastic strategy is to use fail2ban jobs to
block offenders on a temporary basis. But since Postfix is already blocking
the emails from this sender there is no need to do either.

Re: smtp_helo_name not changing.

[Dominic Raferd]

On 23 August 2017 at 08:00, sreeranj s  wrote:

> Thanks Dominic.
>
> Let me explain what exactly is the issue.
> Some of the external email server rejects email from our email servers
> with 450 error. HELO name not resolvable in public DNS. To fix the issue I
> have tried to change smtp_helo_name to match with mx, I have changed the
> smtpd_banner also. However, when I telnet to our server over port 25,
> banner is updated, but HELO still shows old hostname(internal name of
> server). Is there any option to fix the issue.
>
> postconf -n shows the updated smtp_helo_name, but telnet still shows the
> internal name.
>
> I haven't tried changing myhostname parameter, as there seems other
> configuration parameters dependent on it I believe. More over we have a
> passive mail server which always syncs configuration and mailboxes with
> this active server(set up using keepalived).
>
> If I change myhostname, to external DNS name, could you please let me know
> the other parameters that needs modification, like mydestination
>

I doubt the reason for the rejections by external mail servers is your helo
name - this is not normally checked.

In general it's not worth worrying about temporary rejections (4xx code),
only about permanent ones (5xx code). A temporary rejection could be caused
by greylisting, or the external mail server might have some temporary
problem of its own.

If your server has dynamic ip this is a (fatal) reason for rejection by
many servers. Another could be that your ip or rDNS has been blacklisted.​
 But in both cases I would expect to see a 5xx permanent rejection.

I don't know if it is possible to set a non-standard 2nd smtpd response
(after incoming 'helo') which seems to be '250 $myhostname', there is no
smtpd_helo_name parameter to control this, but I don't think it relates to
your problem.

If you want to change myhostname parameter, look at
http://www.postfix.org/postconf.5.html to check what else might change.
Usually it's best to have myhostname the same as your rDNS (public reverse
DNS name of your ip) - given for instance by dig +short -x [external_ip]. I
set it explicitly in main.cf, and don't mess with smtpd_banner nor with
smtp_helo_name.

Re: smtp_helo_name not changing.

[Dominic Raferd]

On 23 August 2017 at 07:11, sreeranj s  wrote:

> I am trying to change smtp_helo_name in our email server(postfix 2.6.6) to
> match with the one in mx record.
>
> I have specified the value as the one given below in main.cf, and
> reloaded the postfix. However telnet still shows the hostname as helo name.
> I could change the smtp_banner, but not smtp_helo_name.
>
> smtp_helo_name = mx.mydomain.com
>

​smtp_helo_name is used for outgoing connections i.e. when postfix sends
email (smtp != smtpd).
smtpd_banner is for how postfix responds to an incoming connection.​

Why not:
myhostname​ = mx.mydomain.com
This is used by default in both smtp_helo_name and smtpd_banner.

​BTW, postfix 2.6.6 is seriously old...​

Re: retry 5xx using a fallback outgoing IP

[Dominic Raferd]

On 9 August 2017 at 12:35, Mai Ling  wrote:

> My small office client upgraded his internet connection and I've updated
> the self hosted postfix configuration file with the new IP address.
>
> Soon after, email users began complaining about bounces they started
> receiving for some emails they sent.
> ​..
>

Just checking, is the new ip dynamic? Dynamic ips are blacklisted by many
rbls automatically (and requests for exceptions will be ignored), so in
this case you must use a relayhost.

Re: exempting user or domain from one RBL check ?

[Dominic Raferd]

On 7 August 2017 at 09:15, Matus UHLAR - fantomas  wrote:

> On 07.08.17 13:17, Voytek wrote:
>
>> I have a user's inbound mail blocked by barracudacentral, is there a way
>> to exempt this particular user/domain from this particular RBL check ?
>>
>
> according to the config line below, putting senders in
> /etc/postfix/sender_checks should prevent postfix from rejecting them at
> SMTP level.
>

and the action should be OK (not DUNNO) e.g.
domain-exempted.dom OK

The OK means that mails from domain-exempted.dom will skip all subsequent
checks in this restriction list (but will not skip any other restriction
lists or tests).



> Is someone rejected despite being in sender_checks?
>
>
> smtpd_recipient_restrictions =
>> reject_unknown_sender_domain,
>> reject_unknown_recipient_domain,
>> reject_non_fqdn_sender,
>> reject_non_fqdn_recipient,
>> reject_unlisted_recipient,
>> check_policy_service inet:127.0.0.1:,
>> permit_mynetworks,
>> check_sasl_access hash:/etc/postfix/sasl_access
>> permit_sasl_authenticated,
>> reject_unauth_destination,
>> check_recipient_access hash:/etc/postfix/recipient_no_checks,
>> check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
>> check_helo_access hash:/etc/postfix/helo_checks,
>> check_sender_access hash:/etc/postfix/sender_checks,
>> check_client_access hash:/etc/postfix/client_checks,
>> check_client_access pcre:/etc/postfix/client_checks.pcre,
>> reject_rbl_client zen.spamhaus.org,
>> reject_rbl_client b.barracudacentral.org,
>
>

Re: DKIM-Signing forwarded email

[Dominic Raferd]

On 5 August 2017 at 17:46, Marco Pizzoli  wrote:

> Hi all,
> I have a postfix instance dedicated to being the main MX (IN).
> I normally use other postfix instances for sending emails out (OUT).
>
> Of course, even this "IN" instance needs to send emails out, mainly
> bounces.
>
> Now I am also implementing forwarding rules: "if you receive an email
> destined to this address, than forward it out to this other email address".
> Other addresses are @gmail.com, @msn.com, etc...
>
> In order to do that "right" I also implemented an SRS service, so to have
> my domain as the envelope sending address.
> Now I also want to enable DKIM-signing of these outgoing emails.
>
> Problem is:
> - SRS (or at least the product I am using, postsrsd) works at the
> "cleanup" level, so after smtpd
> - My DKIM-signing tool is a milter, so acts at smtpd time. So the email it
> sees is with the original sending domain and not my domain.
>
> How can I achieve the intended behaviour?
>

​I am not sure how to achieve this but, even when done, emails will
continue to be rejected by the destination server if it enforces DMARC
(e.g. AOL, Comcast, Hotmail, GMail, Yahoo) and if the domain/sub-domain of
the original sender (in the 'From:' header, unless you rewrite this as
well) has published a DMARC policy with p=reject (e.g. Yahoo, Paypal,
mailing.tesco.com, Lloyds Bank, RBS, HMRC...).

Re: Forward to gmail and DMARC

[Dominic Raferd]

On 14 July 2017 at 16:21, @lbutlr  wrote:

> On 13 Jul 2017, at 15:05, Dominic Raferd  wrote:
> > On 13 July 2017 at 21:06, @lbutlr  wrote:
> >
> > I forward mail to a gmail user, but there are a lot of bounces from
> gmail. I don't honestly care about the ones that google says are spam, but
> recently I'm also getting DMARC failures on Facebook mails.
> >
> > Again, not critical, but a bit annoying.
> >
> > The only thing that I can think to do is disable the forwarding and tell
> the user to grab mail via POP3, but that means enabling POP3 which I'd
> rather not do. Gmail does not, IFAIK, allow you to combine your mail with
> another IMAP account.
> >
> > Any other ideas?
> >
> > ​If you use openDMARC on your own server then rejections by an onward
> mailserver (e.g. Gmail) on the grounds of DMARC failure should only occur
> when the sender has p=reject DMARC policy and is relying on SPF without
> DKIM (or with bad DKIM).
>
> I have to say, I'd be surprised if this is was Facebook was doing, but I
> haven't even looked at DMARC for myself. It's just a milter, yes? And
> required DKIM?
>

​It's a milter, and runs after the opendkim milter. I haven't seen such
behaviour by Facebook, only a few (not all) marketing emails from Tesco (UK
supermarket chain) and a few (again, not all) from Her Majesty's Revenue
and Customs (go figure).​ Most senders with p=reject DMARC policies
understand how to use DKIM and do so.


> > My solution for such cases - which are few - is to trap the DMARC
> failure message from Gmail and then resend the original email as an
> attachment.
>
> Automated? Or is that something you do manually?


Yes I have it automated

Re: Postfix 3.2.0 - Sending to all MX records

[Dominic Raferd]

On 13 July 2017 at 19:14, /dev/rob0  wrote:

> On Thu, Jul 13, 2017 at 02:02:09PM +0100, Dominic Raferd wrote:
> > On 13 July 2017 at 13:56, Daniel Caulfield
> >  wrote:
> >
> > > How would we go about getting you a copy of the 'postfix/smtpd'
> > > logs? where would they be or how do we switch that on?
> >
> > They will be in the same place, you can extract them thus:
> >
> > grep "/smtpd" /var/log/maillog​
>
> This was not good advice, because there are likely relevant bits
> being logged by other Postfix daemon processes.  Also, it likely
> results in a large amount of irrelevant results.


​It was not advice, it was a direct answer to a simple question.​

Re: Forward to gmail and DMARC

[Dominic Raferd]

On 13 July 2017 at 21:06, @lbutlr  wrote:

>
> I forward mail to a gmail user, but there are a lot of bounces from gmail.
> I don't honestly care about the ones that google says are spam, but
> recently I'm also getting DMARC failures on Facebook mails.
>
> Again, not critical, but a bit annoying.
>
> The only thing that I can think to do is disable the forwarding and tell
> the user to grab mail via POP3, but that means enabling POP3 which I'd
> rather not do. Gmail does not, IFAIK, allow you to combine your mail with
> another IMAP account.
>
> Any other ideas?


​If you use openDMARC on your own server then rejections by an onward
mailserver (e.g. Gmail) on the grounds of DMARC failure should only occur
when the sender has p=reject DMARC policy and is relying on SPF without
DKIM (or with bad DKIM). My solution for such cases - which are few - is to
trap the DMARC failure message from Gmail and then resend the original
email as an attachment.

Re: Postfix 3.2.0 - Sending to all MX records

[Dominic Raferd]

On 13 July 2017 at 14:22, Daniel Caulfield 
wrote:

> Hi,
>
> Please find the log attached, is this what you are requesting? (we have had
> to split to multiple files but there are in numarical order)
> smtpd1.log 
> smtpd2.log 
> smtpd3.log 
> smtpd4.log 


​I can't see anything useful here, only that a lot of mails are being sent
to this server but only from 2 local machines. Maybe Viktor can glean
something more from it.
​
It might be more informative if you extract log entries (from any
component) which reference the queue id for one of these mails - for
instance 581DA80219A19 (the last one) thus:

grep 581DA80219A19 /var/log/maillog

Re: Postfix 3.2.0 - Sending to all MX records

[Dominic Raferd]

On 13 July 2017 at 13:56, Daniel Caulfield 
wrote:

> Hi Viktor,
>
> I am working on this issue with Tom, apologies if we seem to be struggling
> with something simple here but the only log file we have is in
> /var/log/maillog. Even if we change the log settings to more verbose we
> don't seem to generate any other logs.
>
> How would we go about getting you a copy of the 'postfix/smtpd' logs? where
> would they be or how do we switch that on?
>
> This system was originally setup by a colleague of ours who is no longer
> working with us, our knowledge is a little more basic than his was.
>

They will be in the same place, you can extract them thus:

grep "/smtpd" /var/log/maillog​

Re: Proper Forwarding Procedure?

[Dominic Raferd]

On 2 July 2017 at 14:31, Dusan Obradovic  wrote:

>
> > On Jun 9, 2017, at 21:45, Steve Jenkins  wrote:
> >
> > I've got a Postfix server hosting a lastname.org domain name for family
> members.
> >
> > I use virtual aliasing to forward inbound mail for family members to
> third-pary mail providers (mostly gmail, but a few yahoo and aol, too).
> >
> > I've also created user accounts on the server for a very small handful
> of immediate family members (4 people) so they can authenticate (via TLS)
> send email as firstn...@lastname.org (which is properly DKIM signed and
> will pass an SPF check).
> >
> > I do not provide any mail storage or retrieval on the server (no POP or
> IMAP) for any family members.
> >
> > This has worked fine for years, but now I'm starting to see warnings in
> the Postfix log from Gmail, stating that the server is being rate-limited
> because of unsolicited messages. I presume that Gmail is sensing SPAM being
> sent to the @lastname.org accounts, which gets forwarded to the family
> member's Gmail account. I don't do any spam checking or filtering on the
> Postfix server.
> >
> > So my questions are:
> >
> > 1) What's the best way to forward family members' incoming mail to Gmail
> (and other mailers)?
> >
> > 2) My Postscreen and main.cf sender restrictions are rejecting a fair
> amount of inbound spam, but apparently not enough to keep Gmail happy.
> >
> > 3) Should I consider setting up SpamAssassin with some very low
> thresholds to pick up the obvious stuff?
> >
> > Thanks in advance,
> >
> > Steve
>
> When forwarding without SRS - Sender Rewriting Scheme you'll need to
> account for SPF failures.


True, but provided your own server is enforcing DMARC (e.g. using
opendmarc) it is only a problem for legitimate incoming mails from a domain
with p=reject DMARC policy and which are incorrectly DKIM-signed (or are
unsigned), and thus depend on SPF (which is broken by relaying) for
delivery. Fortunately such instances are rare.

My (automated) solution in such a case is to rewrite the response code from
the onward server's 550 5.7.1 to 250 2.0.0 and to forward the original
email to the original recipient *as an attachment* with an explanatory
cover message.

Re: Authenticated outgoing email is marked as spam by PBL on mailserver

[Dominic Raferd]

On 16 June 2017 at 10:29, PenguinWhispererThe . <
th3penguinwhispe...@gmail.com> wrote:

> Hi all,
>
> I'm having a problem with valid mails being marked as spam on the MX mail
> server for a domain. See my description below. If you'd need more details
> let me know and I'll be happy to provide. I'm posting this here while this
> might not be a postfix issue itself it is related with how postfix is
> configured an how it might need a configuration change.
>
> Users are sending email, authenticated, through the submission port on my
> mailserver (their domain MX record points to mailserver; postfix).
>
> What's been setup
>
>- A record
>- MX record (pointing to same mailserver for all domains)
>- PTR record resolving to mailserver name
>- DKIM: pass
>- SPF: pass
>- DMARC: pass
>- MailScanner with clamd and spamassassin
>- SASL authentication (mail headers mention user is authenticated)
>- No open relay
>- TLS
>- ...
>
> I see that mails are authenticated in the headers.
>
> However I see that spamassassin marks it as spam (it mentions that the IP
> of the client is on the RBL). When I query spamhaus I see that the client
> IP (which is dynamic due to mobile ISP). Zenhaus says it's on the PBL, so
> basically it is marked as spam as a policy based on the client IP.as
>
> Apart from that there's nothing wrong with those emails. The other ISPs
> don't have this problem and the emails are then delivered properly.
>
> Now on to my questions... :)
>
>- is mail send through submission port supposed to go through
>Mailscanner (spamassassin + clamd)? I would suppose yes as it would already
>prevent people from sending spam in the first place (instead of preventing
>spam email to be delivered). On the other hand a receiving mailserver can't
>trust what's in the headers so it'll probably check it anyway.
>- Is there a way to not mark as spam if only mentioned on the PBL?
>- Will releasing the message make it deliverable? Or will it just move
>the problem? (so the receiving mailserver might check and mark as spam due
>to the PBL) If it moves the problem it doesn't seem a valid solution to try
>to bypass the PBL for authenticated users.
>- Will a receiving mailserver only check the last header (so the
>header added by my mail server)? In this case disabling spam check might
>actually resolve the issue and not move it on to the next machine).
>- another thing that comes to mind is removing/modifying the first
>header so the IP is no longer mentioned. However this seems like a bad
>practice.
>- What's the proper/appropriate way to handle this?
>
> For clarity: the mails are received on the smtp server that the users have
> configured on their laptop/mobile and put in the postfix queue. So no
> direct rejection to the clients. Only after mailscanner jumps in and checks
> the email before sending (in this case marking it as spam and not sending
> it).
>

The reason that other mailservers don't have any problem with emails from
your dynamic ips is that the emails are 'cleansed' of their dynamic IP by
being forwarded through your static-ip server. So no problem releasing them
for onward delivery - the only IP that an onward server is likely to
consider is the client's (i.e. of your server), not what any headers might
say in the message about previous hops.

I'm not sure what the 'proper' way to handle this, but here are a few
possibilities:

​A way to prevent spamassassin from inspecting mail from authenticated​
senders is suggested at
https://serverfault.com/questions/33518/postfix-skip-spam-checks-for-authorized-smtp
.

I use spamassassin+clamd via amavis; it does check mail from authenticated
senders but I have turned off all RBL checks in spamassassin and instead
have postfix perform these - but only for non-authenticated senders. Like
this (suggestions for improvement welcome):

smtpd_sender_restrictions =
permit_sasl_authenticated
permit_mynetworks # only the local machine
# check_sender_access: REJECT emails (by envelope address) from a few
known spam senders, OK a very few 'false positives'
check_sender_access hash:/etc/postfix/check_sender_access
# check_client_access: OK a very few ips prone to 'false positives'
check_client_access hash:/etc/postfix/check_client_access
reject_unauth_pipelining
# accept whitelisted per hostkarma, dnswl.org, uribl.com
permit_dnswl_client hostkarma.junkemailfilter.com=127.0.0.1
permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3]
permit_dnswl_client white.uribl.com
# check against spamhaus etc
reject_rbl_client zen.spamhaus.org
[... and others similar]
reject_rhsbl_helo dbl.spamhaus.org
[... and others similar]
reject_rhsbl_sender dbl.spamhaus.org
[... and others similar]
reject_rhsbl_reverse_client dbl.spamhaus.org
[... and others similar]

I think it is regarded as better practice to use postscreen instead, 

Re: Fwd: How to bounce a queued mail

[Dominic Raferd]

On 15 June 2017 at 17:02, Noel Jones  wrote:

> On 6/15/2017 6:34 AM, Dominic Raferd wrote:
> >
> >
> > On 15 June 2017 at 11:58, Wietse Venema  > <mailto:wie...@porcupine.org>> wrote:
> >
> > Dominic Raferd:
> > > We occasionally get emails in our postfix queue that can never
> > be delivered
> > > but which are held in the queue for a week before postfix
> > bounces them
> > > (example: sender has typed gmail.co <http://gmail.co> instead
> > of gmail.com <http://gmail.com>). I realise this
> > > delay is the correct behaviour, but how can I - by exception -
> > bounce a
> > > queued mail immediately, with notification back to sender?
> >
> > See the thread "How to bounce malformed addresses ?" from a few
> > days ago.
> >
> >
> > ​I think my situation is different. In that thread the problem was
> > that sender never received bounce notification (for some reason). In
>
> At any rate, the solution is the same. Use transport_maps to return
> an immediate error for misbehaving domains such as gmail.co.
>
> If you already have mail queued for gmail.co, you can add the
> transport_maps entry as described in the earlier thread and postfix
> will bounce the offending message on the next queue run.


​I have indeed done that, thanks. For the identified misspellings it is a
perfect solution.

Re: Fwd: How to bounce a queued mail

[Dominic Raferd]

On 15 June 2017 at 13:14, Bastian Blank <
bastian+postfix-users=postfix@waldi.eu.org> wrote:

> On Thu, Jun 15, 2017 at 12:34:14PM +0100, Dominic Raferd wrote:
> > ​I think my situation is different. In that thread the problem was that
> > sender never received bounce notification (for some reason). In my
> > situation, the bounce notification will be issued (and received by
> sender)
> > at the correct time ​(i.e. after one week) but I would like a way to
> > trigger this earlier for some emails stuck in the queue.
>
> For a dedicated MSA it might be worthwhile to set delay_warning_time to
> some smaller time (a few hours).


​Thanks for the suggestion, I now have done that too (I set 90m).​

Fwd: How to bounce a queued mail

[Dominic Raferd]

On 15 June 2017 at 11:58, Wietse Venema  wrote:

> Dominic Raferd:
> > We occasionally get emails in our postfix queue that can never be
> delivered
> > but which are held in the queue for a week before postfix bounces them
> > (example: sender has typed gmail.co instead of gmail.com). I realise
> this
> > delay is the correct behaviour, but how can I - by exception - bounce a
> > queued mail immediately, with notification back to sender?
>
> See the thread "How to bounce malformed addresses ?" from a few days ago.


​I think my situation is different. In that thread the problem was that
sender never received bounce notification (for some reason). In my
situation, the bounce notification will be issued (and received by sender)
at the correct time ​(i.e. after one week) but I would like a way to
trigger this earlier for some emails stuck in the queue.

A week's delay in receiving a non-notification message for a response to a
sales lead may lose the sale opportunity (you might expect response is to a
valid email address but here sender is responding to a manually-entered
'Reply-To' address on a web form). Once sender has the non-notification
message (s)he might spot the typo or be able to use another contact method.

Rather than deleting an item from the queue (postsuper -d) I want a way -
by exception - of defining it as failed thus triggering immediate bounce
notification (i.e. before the week has expired). Maybe some option to
postsuper that I haven't understood?

In the meantime I have implemented Noel's helpful suggestions (in the
aforementioned thread) for rejecting mails to commonly-mistyped domains -
using transport table.

How to bounce a queued mail

[Dominic Raferd]

We occasionally get emails in our postfix queue that can never be delivered
but which are held in the queue for a week before postfix bounces them
(example: sender has typed gmail.co instead of gmail.com). I realise this
delay is the correct behaviour, but how can I - by exception - bounce a
queued mail immediately, with notification back to sender?

Re: problem with sender_access ; can't reject domains

[Dominic Raferd]

On 12 June 2017 at 10:04, pat G  wrote:

> hello,
>
> i use postfix since years, there was no problem, but since some weeks, we
> receive mails from bad domains.
>
> i don' t find solution in postfix. i use "sender_access" to reject some
> domains, but domains are always coming even if i postmap sender_access and
> i restart postfix. what can be the solution ? i use  : check_sender_access
> hash:/etc/postfix/sender_access
>
> here my postconf -n : 
> http://paste.debian.net/971113/
>

​Maybe you trying to reject based on the domain in the 'From' header not
the domain in the envelope sender. sender_access works off the envelope
sender only, if you want to reject based on the address in the 'From'
header you need to use header_checks
.

Re: Proper Forwarding Procedure?

[Dominic Raferd]

On 10/06/2017 20:03, Philip Paeps wrote:
On 2017-06-09 21:10:12 (+0100), Dominic Raferd 
 wrote:

On 9 June 2017 at 20:45, Steve Jenkins  wrote:
I've got a Postfix server hosting a lastname.org domain name for 
family members.


I use virtual aliasing to forward inbound mail for family members to 
third-pary mail providers (mostly gmail, but a few yahoo and aol, too).


I've also created user accounts on the server for a very small 
handful of immediate family members (4 people) so they can 
authenticate (via TLS) send email as firstn...@lastname.org (which 
is properly DKIM signed and will pass an SPF check).


I do not provide any mail storage or retrieval on the server (no POP 
or IMAP) for any family members.


This has worked fine for years, but now I'm starting to see warnings 
in the Postfix log from Gmail, stating that the server is being 
rate-limited because of unsolicited messages. I presume that Gmail 
is sensing SPAM being sent to the @lastname.org accounts, which gets 
forwarded to the family member's Gmail account. I don't do any spam 
checking or filtering on the Postfix server.


So my questions are:

1) What's the best way to forward family members' incoming mail to 
Gmail (and other mailers)?


2) My Postscreen and main.cf sender restrictions are rejecting a 
fair amount of inbound spam, but apparently not enough to keep Gmail 
happy.


3) Should I consider setting up SpamAssassin with some very low 
thresholds to pick up the obvious stuff?


I have a not-dissimilar setup and I have various fixes to minimise 
Gmail's upset. But I guess the first q is whether you need to be 
worried about the 'rate-limited' messages. If you have a low volume 
of incoming emails anyway a bit of rate-limiting is hardly likely to 
be a problem.


The rate-limiting may not be a big problem long-term but eventually 
all email coming from you will be filed as spam.  And then users will 
blame you for that ...


I certainly assumed the same when designing my system, which takes a 
range of measures to minimise such emails - both spam/virus blocking of 
its own, and reacting swiftly to any messages received back from Gmail.


I was not brave enough to ignore Gmail's rate-limiting (and other) 
messages and see what if anything happened next (like the OP we have 
very low volumes of legitimate incoming mail). All I can say is that 
during the several months it took me to 'perfect' the system, we weren't 
blocked by Gmail nor were our forwarded emails filed by Gmail as spam. 
(Gmail continues to provide a good 'final spam filter' service for us 
after the more egregious rubbish has been filtered out by our own system.)


If someone has direct experience of uniform blocking and/or spam-filing 
by Gmail (against an 'innocent' forwarder) then I would be interested 
(and feel that my work was not after all a waste of time...)

Re: Proper Forwarding Procedure?

[Dominic Raferd]

On 9 June 2017 at 20:45, Steve Jenkins  wrote:

> I've got a Postfix server hosting a lastname.org domain name for family
> members.
>
> I use virtual aliasing to forward inbound mail for family members to
> third-pary mail providers (mostly gmail, but a few yahoo and aol, too).
>
> I've also created user accounts on the server for a very small handful of
> immediate family members (4 people) so they can authenticate (via TLS) send
> email as firstn...@lastname.org (which is properly DKIM signed and will
> pass an SPF check).
>
> I do not provide any mail storage or retrieval on the server (no POP or
> IMAP) for any family members.
>
> This has worked fine for years, but now I'm starting to see warnings in
> the Postfix log from Gmail, stating that the server is being rate-limited
> because of unsolicited messages. I presume that Gmail is sensing SPAM being
> sent to the @lastname.org accounts, which gets forwarded to the family
> member's Gmail account. I don't do any spam checking or filtering on the
> Postfix server.
>
> So my questions are:
>
> 1) What's the best way to forward family members' incoming mail to Gmail
> (and other mailers)?
>
> 2) My Postscreen and main.cf sender restrictions are rejecting a fair
> amount of inbound spam, but apparently not enough to keep Gmail happy.
>
> 3) Should I consider setting up SpamAssassin with some very low thresholds
> to pick up the obvious stuff?
>

​I have a not-dissimilar setup and I have various fixes to minimise Gmail's
upset. But I guess the first q is whether you need to be worried about the
'rate-limited' messages. If you have a low volume of incoming emails anyway
a bit of rate-limiting is hardly likely to be a problem.

Re: Forward SRS with postfix

[Dominic Raferd]

On 8 June 2017 at 12:20, Marek Kozlowski  wrote:

> :-)
>
> On 06/08/2017 12:38 PM, Dominic Raferd wrote:
> > On 08/06/2017 10:55, Marek Kozlowski wrote:
> >> :-)
> >>
> >> Numerous users of my system use forward to external MTAs. From time to
> >> time it causes some issues with SPF on those MTAs. SRS could resolve
> >> those.
> >> I'm wondering if you could recommend any SRS software which nicely
> >> integrates with postfix and doesn't interfere with canonicals (postsrsd
> >> does[*])...
> >>
> >
> > We forward our users' incoming mails through our postfix servers to
> > external MTAs (almost always Gmail). Yes it breaks SPF but it is not
> > usually a problem, because it doesn't break DKIM. It would of course be
> > a problem if the external MTAs chose to enforce rejection based purely
> > on SPF; a very unwise practice IMO, but there may not be much you can do
> > about it.
> >
> > In our case (with Gmail as the external MTA) it is only a problem if the
> > source domain has a 'reject' DMARC policy and the original message,
> > though passing SPF, fails DKIM (probably because it is unsigned). Our
> > system monitors the log for such a rejection (by Gmail) and if found
> > will then encapsulate the original message and re-send it to recipient
> > (with an explanatory text). In my experience such instances are very
> rare.
>
> I've recently implemented opendkim. As far as I understand your
> explanation if the message is DKIM-signed I should not worry too much
> about SRS?


To be honest ​I haven't tried SRS; but if it doesn't break DKIM I would
expect it to break DMARC (because of alignment concept). Maybe someone
knows different?

Our servers use openDMARC; openDKIM and python-policyd-spf are used but
only to add informational headers for openDMARC. We enforce p=reject DMARC
policy but (in another coded workaround) any mail placed by openDMARC in
the postfix hold queue (p=quarantine DMARC policy) is released​ and sent
onward so that the end MTA (Gmail) can receive and quarantine it (i.e. put
into Gmail 'Spam' folder).

Re: Forward SRS with postfix

[Dominic Raferd]

On 08/06/2017 10:55, Marek Kozlowski wrote:

:-)

Numerous users of my system use forward to external MTAs. From time to
time it causes some issues with SPF on those MTAs. SRS could resolve those.
I'm wondering if you could recommend any SRS software which nicely
integrates with postfix and doesn't interfere with canonicals (postsrsd
does[*])...



We forward our users' incoming mails through our postfix servers to 
external MTAs (almost always Gmail). Yes it breaks SPF but it is not 
usually a problem, because it doesn't break DKIM. It would of course be 
a problem if the external MTAs chose to enforce rejection based purely 
on SPF; a very unwise practice IMO, but there may not be much you can do 
about it.


In our case (with Gmail as the external MTA) it is only a problem if the 
source domain has a 'reject' DMARC policy and the original message, 
though passing SPF, fails DKIM (probably because it is unsigned). Our 
system monitors the log for such a rejection (by Gmail) and if found 
will then encapsulate the original message and re-send it to recipient 
(with an explanatory text). In my experience such instances are very rare.

Re: header_checks and custom header fails to trigger

[Dominic Raferd]

On 6 June 2017 at 07:49, rolelael  wrote:

> Hello
>
> It's me again and the header_checks is driving me crazy
>
> Mail comming from other mail system comes into postfix were header_checks
> is
> enabled
>
> The mail system adds a header :
>
> route_gcgw: BE
>
> This header is visible when the mail is received
>
> I have a header_checks file where 'again' the if statement is not triggered
> :
>
> if /^route_gcgw: BE/
> /^Received:.*test\.be/ WARN warningOOOtestdomainT
> /^Received:.*testf\.be/ WARN warningOOOtestdomainF
> endif
>
> I also tried
>
> if /^route_gcgw:.*BE/
>
> &
>
> if /^route_gcgw:.*BE.*/
>
> Nothing seems to be working.
>
> What I'm a doing wrong here ?
>
>
​You can't perform a multi-line test like this. Please look at
http://www.postfix.org/header_checks.5.html especially the 'BUGS' section:
'These rules operate on one logical message header or one body line at a
time. A decision made for one line is not carried over to the next line.'​

Re: non_smtpd_milters and canonical_maps - what goes first?

[Dominic Raferd]

On 3 June 2017 at 14:01, Wietse Venema  wrote:

> Marek Kozlowski:
> [ Charset ISO-8859-2 converted... ]
> > On 06/03/2017 02:13 PM, Wietse Venema wrote:
> > >>> Canonical maps replace headers or envelopes before the entire message
> > >>> is received.  Milters replace/add/delete envelope or content after
> > >>> the entire message is received.
> > >>
> > >> I'm not quite sure if I understand the term you use: `before/after the
> > >> entire message is received'. I'd really appreciate any clarification.
> > >> BTW: Is there any way to change the order?
> > >
> > > To answer the first question, 'before' refers to events that happen
> > > earlier than 'after'.  Changing the order requires time travel or
> > > the ability to predict the future. The second question makes no
> > > sense at this point in time.
> >
> > ;-)))
> >
> > My question regarded: `the entire message is received'. With the stress
> > on `entire'. I thought that local receives a message as a whole. You
> > answer suggested that it receives messages partially. Some part, than
> > the canonical starts working then the rest and then a milter operates?
>
> Perhaps surprisingly, Postfix uses the same Milter support
> for mail received from the network and from local submission.
> Mail in the postdrop queue is not received. It is waiting
> to be received by the Postfix mail system.
>
> Wietse
>

​Time travel is one way to change the order (i.e. process milter before
canonical_maps), but couldn't it also be done by re-injection?

Time travel sounds more fun though, please provide working example.​

Re: Reject any sender having the word "welcome" in the email address.

[Dominic Raferd]

On 22 May 2017 at 16:23, Clifford Gonsalves 
wrote:

> Hello,
>
> I would like to block any sender having the word "welcome" in the email
> address.
>
> I know this can be done with header_checks, I just need the syntax to add
> this rule.
> ​..
>

I think this should work:

​​main.cf:
header_checks = pcre:/etc/postfix/check_headers

check_headers:
/^From:.*welcome.*@/ REJECT

Re: remove multi line config entry with sed

[Dominic Raferd]

On 12 May 2017 at 12:56, Geert Stappers  wrote:

>
> ​...
>
> ​
>
> sed --silent '/^uucp/{:a;N;/^ +/ba};p'
> ​​
> /etc/postfix/master.cf
>
> Yields _all_ lines, expected/wanted is
>
> uucp  unix  -   n   n   -   -   pipe
>   flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
> ($recipient)
>
>
> How to get that result??
>

​Not a postfix question, but this should work:

sed --silent '/^uucp/{:a;N;/^ +/ba;p}'​
​
/etc/postfix/master.cf

Re: policyd_spf

[Dominic Raferd]

On 10 May 2017 at 15:27, marco  wrote:

> Is there any way of having in the log the debugging info for the
> policyd_spf?
> I have been using for a test smtp -v in master.cf, but this is producing
> an enormous quantity of data, and policyd_spf -d in master.cf fails with
> errors.
> My target is to have a first impression after the installation, and then
> collect the policyd_spf answers to verify the efficieny of SPF for my sites
> (currently I see a lot of DONNO even for Google)


Look in man policyd-spf.conf LOGGING section.​

Re: smtp_bind_address isn't working

[Dominic Raferd]

On 25 April 2017 at 21:19, Tumbleweed  wrote:

> I’m setting up my first mail server.
>
> I’ve installed Postfix, configured a few options, and can send mail
> successfully. I have two addresses, one IPv4 and one IPv6, and I’ve set up
> my SPF record to my IPv4, which is the one I’d like to use to send emails.
> The problem is that Postfix refuses to send emails from that IPv4 address
> alone, instead choosing to send email from my IPv6 address about half the
> time. In main.cf, I’ve tried every relevant combination of
> smtp_bind_address, smtp_bind_address6, inet_interfaces, and mynetworks that
> I can think of. I’ve also tried setting smtp_bind_address in master.cf as
> described here: http://www.postfix.org/postconf.5.html#smtp_bind_address.
> I
> also followed the debugging instructions
> (http://www.postfix.org/DEBUG_README.html) to the best of my ability, but
> I’m afraid I tapped out when I got to the “tracing the program” steps; I
> just don’t have the requisite C ability.
>
> System: Debian Stable, Postfix version 2.11.3-1
>

​Try: inet_protocols 
= ipv4

​

Re: mydomain and myhostname

[Dominic Raferd]

On 18 April 2017 at 16:35, Christoph Pleger  wrote:

> Hello,
>
> I have here two different postfix installations, one is postfix 2.11.3-1
> from Debian 8, the other is postfix 3.1.0-3 from Ubuntu 16.04. /etc/postfix/
> main.cf is the same on both machines, mydomain and myhostname are not set
> in main.cf . When I call postconf, I get
>
> mydomain = cs.uni-dortmund.de
> myhostname = cloudhost177.cs.uni-dortmund.de
>
> on the Debian machine, but
>
> mydomain = localdomain
> myhostname = cloudhost176.localdomain
>
> on the Ubuntu machine.


>From http://www.postfix.org/postconf.5.html#myhostname: the default [for
myhostname] is to use the fully-qualified domain name (FQDN) from
gethostname(), or to use the non-FQDN result from gethostname() and append
".$mydomain"

- i.e. what you see when you type 'hostname' at the command line, which in
turn is usually taken from the contents of /etc/hostname. And mydomain is
by default derived from myhostname. If you update /etc/hostname you may
also need to update /etc/hosts.

Re: Recommended way to pause postfix local delivery while taking snapshot for backup

[Dominic Raferd]

Thanks to all for the replies. This is an existing somewhat elderly setup
and I don't want to make major changes (file system, LMTP etc) at this
stage. For postfix, Wietse's suggestion should work nicely. I guess I
should build in a delay of a second or two after issuing the command to
ensure that any local deliveries in progress are completed before the
snapshot is taken - this is not a very big/busy server. For dovecot well I
will just stop it. So something like this:

postconf defer_transports=local
postfix reload
sleep 2s
/etc/init.d/dovecot stop # (this is on Debian 6.0, no systemd)
# take lvm snapshot here, then:
postconf defer_transports=
postfix reload
/etc/init.d/dovecot start
# backup from snapshot can now proceed

On 9 April 2017 at 15:29, Viktor Dukhovni 
wrote:

>
> > On Apr 9, 2017, at 4:52 AM, Dominic Raferd 
> wrote:
> >
> > Is there a best/recommended way to pause postfix local deliveries so that
> > I can take an LVM snapshot of the local mails for backup purposes?
>
> The "best" way is to use a file system that supports snapshots, such as
> "zfs".  Otherwise, what Wietse said about "defer_transports".  Covers
> the Postfix part.
>
> > The pause only has to be momentary, while the snapshot is taken, but the
> > files need to be in a consistent state. If anyone also knows the way to
> > pause Dovecot imap/pop3 similarly (as this could also be accessing the
> > same files), that would be helpful too.
>
> You'd have to stop Dovecot, terminating all active connections, or use
> a file-system that supports snapshots.
>
> With maildir, you can probably not worry too much about consistency,
> and just do periodic rsync without stopping Postfix or Dovecot.
>
> --
> Viktor.
>
>

Recommended way to pause postfix local delivery while taking snapshot for backup

[Dominic Raferd]

Is there a best/recommended way to pause postfix local deliveries so that I
can take an LVM snapshot of the local mails for backup purposes? The pause
only has to be momentary, while the snapshot is taken, but the files need
to be in a consistent state. If anyone also knows the way to pause Dovecot
imap/pop3 similarly (as this could also be accessing the same files), that
would be helpful too.

Re: need little help with DKIM, if possible.

[Dominic Raferd]

On 30 March 2017 at 17:42, Viktor Dukhovni 
wrote:

>
> > On Mar 30, 2017, at 12:35 PM, Dominic Raferd 
> wrote:
> >
> > As I understand it, ​DKIM requires a separate DNS record for each
> subdomain
>
> No, DKIM has no such requirement.  The DKIM signing domain "d=" in the
> DKIM signature header is not constrained to match the domain in the
> rfc2822 "From:" header.  All that DKIM conveys is the identity of the
> domain responsible for the content.  DKIM authenticates the origin
> domain, not the author.


​Thanks Viktor on reflection that is clearly right. What I should have said
is that valid DKIM only proves that the content of the email came from the
domain in the From header​ if this domain matches the one in the DKIM
header.

BTW I recently discovered a neat Thunderbird Add-On 'DKIM Verifier' which
can colour(color) the background to the sender name (i.e. From header)
green if the domain matches the DKIM domain (example: P.V. Anthony's email
in this thread, mine too I hope), orange if they mismatch (example:
Angelo's emails in this thread), no colour if there is no DKIM (example:
your emails in this thread), red if the DKIM signature is bad.

Re: need little help with DKIM, if possible.

[Dominic Raferd]

​​


On 30 March 2017 at 16:19, Fazzina, Angelo  wrote:

> Thank you Dominic,
>
>
>
> I think I am starting to confuse the 2 sides of the coin and wanted
> clarification.
>
>
>
> If I setup DKIM, it is to be used by whom ?
>
> Is it for anyone including my own domain, when an @uconn.edu email is
> received, it is to be checked ?
>
>
>
> A.  Does my DKIM entry in DNS help with sending from x...@example.com
>  to x...@uconn.edu ?
>
> B.  Does my DKIM entry in DNS help with sending from x...@uconn.edu to
> x...@example.com?
>
> C.  Does my DKIM entry in DNS help with sending from  x...@uconn.edu
> to y...@uconn.edu ?
>
>
>
> In “C” I am thinking emails from staff to student and vice versa. Staff on
> O365 and students on Google Apps.
>
> Both cloud solutions.
>
> *Student to staff* would go  google ->  to my MX record which is spam
> appliance -> postfix box -> O365 servers
>
> *Staff to Student*  would go O365 -> to my MX record which is spam
> appliance -> postfix box  -> Google servers
>

As I understand it, ​DKIM requires a separate DNS record for each subdomain
to which it will apply (unlike DMARC). So if you want to send emails with
header 'From: ​​alf02013@​​appmail.uconn.edu' and you want these to have a
useful DKIM header, then there must be a DNS TXT entry at mykey._
domainkey.appmail.uconn.edu, and the private key to which this relates must
have been used by your mailserver to generate the DKIM header (with
s=mykey) that appears in your email. With a separate but similar DNS TXT
entry at mykey._domainkey.uconn.edu, the same private key could be used by
your mailserver to generate a valid DKIM header for an email from
angelo.fazz...@uconn.edu.

*Any* MUA can check your DKIM header to see whether the email is unmodified
since the DKIM header was created by the private keyholder; but a valid
DKIM header means very little unless it matches (is 'aligned with') the
domain in the 'From' header, since a malefactor can still create an email
faking your 'From' address and insert their own valid DKIM header based on
their own domain (which will verify against their DNS TXT record). DMARC
takes DKIM and adds in the concept of alignment, but of course it first
requires that you are using DKIM.

Unfortunately in the real world DKIM is often used badly, including by
large organisations that should know better, so an unaligned DKIM header
(or one that is faulty in some other way) is only an indication that
there *just
might* be a problem and nothing more. Similarly the presence of a DKIM TXT
entry in DNS does not guarantee that all valid emails from this domain will
have a DKIM header. This is another advantage of DMARC with p=reject,
because no organisation can afford to have such a policy unless it is
confident that its emails will all be correctly signed and aligned.

If any of the above is wrong, I hope someone will explain better.

Dominic

Re: problem with protection.outlook.com released spam getting bounced

[Dominic Raferd]

On 30 March 2017 at 15:26, John Stoffel  wrote:

>
> Hi all,
>
> We're running postfix-2.6.6-6.el6_5.x86_64 on RHEL 6.6 and running
> into a problem where emails that have been released from our outside
> spam protection company, *.protection.outlook.com, are getting
> rejected with messages like this:
>
>   Mar 26 06:00:56 mailhost postfix/smtpd[2270]: connect from
> mail-sn1nam01lp0113.outbound.protection.outlook.com[207.46.163.113]
>   Mar 26 06:00:56 mailhost postfix/smtpd[2270]: 51235A07D1: client=
> mail-sn1nam01lp0113.outbound.protection.outlook.com[207.46.163.113]
>   Mar 26 06:00:56 mailhost postfix/cleanup[2279]: 51235A07D1: message-id=<
> 1490445496218.20153408.25880761.5137938...@backend.ttktravelinsider.com>
>   Mar 26 06:00:56 mailhost postfix/qmgr[27442]: 51235A07D1: from=<
> ttkpub.nore...@ttktravelinsider.com>, size=40439, nrcpt=1 (queue active)
>   Mar 26 06:00:56 mailhost postfix/local[2278]: 51235A07D1: to=<
> saba.shar...@sub.com>, relay=local, delay=0.29, delays=0.28/0/0/0.01,
> dsn=5.4.6, status=bounced (mail forwarding loop for saba.shar...@sub.com)
>   Mar 26 06:00:56 mailhost postfix/bounce[2273]: 51235A07D1: sender
> non-delivery notification: 97DF2A080B
>   Mar 26 06:00:56 mailhost postfix/qmgr[27442]: 51235A07D1: removed
>
> These emails are released by the end user and should be delivered, but are
> getting bounced back.
>
> How would I go about figuring out if it's really a bogus "Delivered-To: "
> header that's causing this rejection?


Did you see this earlier thread:
http://postfix.1071664.n5.nabble.com/What-is-causing-this-mail-forwarding-loop-bounce-td62199.html
?
​

Re: need little help with DKIM, if possible.

[Dominic Raferd]

On 29 March 2017 at 20:36, Fazzina, Angelo  wrote:

> Thank you Doug,
>
> I fixed the name so the unsupported character "_" is not used.
>
> Please review my latest test, as I have a question.
>
>
>
> Is there anything in the DKIM config files I can change to get rid of this
> message ?
>
>
>
> *Authentication-Results: verifier.port25.com ;
> dkim=pass (signature verifies; identity doesn't match any headers)
> header.d=mta4.uits.uconn.edu *
>
>
>
> Am I supposed to get the headers to match ?
>
> DKIM check details:
>
> Result: pass (signature verifies; identity doesn't match any
> headers)
>
> ID(s) verified: header.d=mta4.uits.uconn.edu
>
> Canonicalized Headers:
>
> to:check-a...@verifier.port25.com'0D''0A'
>
> from:"Fazzina,'20'Angelo"'20'< 
> ​​ 
> alf02013@ 
>
> ​​ 
> appmail.uconn.edu >'0D''0A'
>
> date:Wed,'20'29'20'Mar'20'2017'20'15:29:26'20'-0400'0D''0A'
>
> dkim-signature:v=1;'20'a=rsa-sha256;'20'c=relaxed/simple;'20'd=
> 
> ​​ 
> mta4.uits.uconn.edu;'20's=dkim1;'20't=1490815766;'20'bh=
> frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;'20'h=To:From:
> Date:From;'20'b=
>
>
​The problem I think is that you have set up a dkim record for emails from
domain ​
​
mta4.uits.uconn.edu but you are sending an email from
​
appmail.uconn.edu  (i.e. the internal 'From:'
header is set to
​ 
alf02013@ 
​​ 
appmail.uconn.edu ). Hence the report that the
dkim identity ('d=') doesn't match any headers.

Re: Whitelisting past a sender with no A/MX record?

[Dominic Raferd]

On 27 March 2017 at 17:25,  wrote:

> Hello,
>
> I'm getting the following log msg for a user (u...@example.com),
>
> Mar 26 13:22:19 bigben postfix/ps2/smtpd[32481]: NOQUEUE: reject:
> RCPT from chrelay.taleo.net[68.233.76.14]: 450 4.1.8
> : Sender address rejected: Domain not
> found; from= to=
> proto=ESMTP helo=
>
> in my Postfix 3.2 logs.
>
> I note that JPMCStaffing.com has no legit A/MX record.
>
> dig ANY JPMCStaffing.com
>
> ;; ANSWER SECTION:
> JPMCStaffing.com.   1883IN  SOA
> ns1.jpmorganchase.com. hostmaster.jpmchase.com. 478475997 10800 1800
> 1209600 3600
> JPMCStaffing.com.   1883IN  TXT "v=spf1
> include:taleo.net -all"
> JPMCStaffing.com.   1883IN  NS
> ns1.jpmorganchase.com.
> JPMCStaffing.com.   1883IN  NS
> ns05.jpmorganchase.com.
> JPMCStaffing.com.   1883IN  NS
> ns06.jpmorganchase.com.
> JPMCStaffing.com.   1883IN  NS
> ns2.jpmorganchase.com.
>
> Since
>
> (a) it's a legit email
> (b) it's a legit sender
> (c) they're too $&^$& big to be able to get anyone to respond, let
> alone fix their end (Working on it ...)
>
> I just want to whitelist past them.
>
> My main.cf has
>
> ps2  pass  -  -  n  -  -  smtpd
>   -o syslog_name=postfix/ps2
>   -o smtpd_relay_restrictions=permit_mynetworks,reject_
> unauth_destination,permit
>   -o smtpd_proxy_filter=127.0.0.1:10001
>   -o smtpd_authorized_xforward_hosts=127.0.0.0/8
>
> my master.cf includes
>
> smtpd_client_restrictions =
> permit_mynetworks
>
> ​​
> check_client_access lmdb:/etc/postfix/client_whitelist
> reject_unknown_reverse_client_hostname
> reject_unauth_pipelining
>
>
> ​​
> smtpd_sender_restrictions =
> permit_mynetworks
> permit_tls_clientcerts
> reject_non_fqdn_sender
>
> ​​
> reject_unknown_sender_domain
> permit
>
> and
>
> cat /etc/postfix/client_whitelist
> 68.233.76.0/24OK
> 68.233.76.14  OK
>
> Iiuc, SMTPD 'MUMBLE' RESTRICTIONS get checked in this order
>
> client, helo, sender, relay, recipient, data, or end-of-data
>
> So I was hoping that my whitelist would prevent that reject.
>
> Clearly, not working like I thought :-(
>
> What do I need to configure to get Postfix/Postscreen to PASS this sender?
>
>
I think the rejection you are seeing is being generated by
​
reject_unknown_sender_domain. OKing an email in one restriction list only
affects tests later in that same list, not tests in other restriction
lists.​ Try adding the line '
​
check_client_access lmdb:/etc/postfix/client_whitelist' to ​
​the
smtpd_sender_restriction list, after permit_mynetworks.

Re: Encapsulate incomming bounce mail

[Dominic Raferd]

On 4 March 2017 at 17:55, Viktor Dukhovni  wrote:
>
>> On Mar 4, 2017, at 9:56 AM, Dominic Raferd  wrote:
>>
>> I have a similar situation. I wrote a script which spots the relevant
>> bounce message in the mail log, from this it extracts the queue-id and
>> uses this to identify the copy of the original email saved in the
>> temporary local mailbox (which saves all mails passing through the
>> server). It extracts this email from there and forwards it as an
>> attachment to the relevant person using s-nail, with an explanatory
>> cover message. The same approach might work for you.
>
> This is much too complex.  To attach email message to another message,
> just pipe it through the shell script below my signature.  This can
> be used as part of a pipe(8) transport with the output submitted via
> sendmail(1) for delivery.
>
> --
> Viktor.
>
> #! /bin/sh
>
> sender=postmaster
> rcpt=lu...@example.com
>
> cat < From: $sender
> To: $rcpt
> Subject: Encapsulated bounce for your perusal
> MIME-Version: 1.0
> Content-Type: message/rfc822
>
> EOF
> cat

That gets round the s-nail dependency (the final step in my script),
so thank you, but in my case (not so sure about OP) I need to recover,
and send on as encapsulated, the original email that has just been
bounced by the onward server, not the bounce message itself. Apart
from your change to this final step, is there a much easier approach
than mine in this situation?

Re: Encapsulate incomming bounce mail

[Dominic Raferd]

On 4 March 2017 at 13:53, Dirk Stöcker  wrote:
> On Tue, 28 Feb 2017, Noel Jones wrote:
>
>>> in one project I'm sending a bunch of status mails to a number of
>>> different recepients. From time some of them cannot be delivered
>>> (address changes, server misconfigurations, employment changes, ...).
>>>
>>> The bounces from the mail come back to my mail server and should go
>>> to a contractor of us managing the e-mail addresses.
>>
>>
>> Stop there.  The mail envelope sender should direct bounces to the
>> party responsible, and they should deal with the mail directly.  Set
>> the envelope sender properly and don't use crappy workarounds.
>
>
> The mail is bounced to the server responsible for it - my mail server.
>
> The "deal with the mail" is what I'm talking here, because I must inform
> somebody else about the bounce. I'm searching a simple way to make the
> bounce mail available in a form that it is not rejected by mailinglist
> software with automatic bounce detection.
>
> Currently I manually write a mail from time to time telling them about the
> bouncing mails and the reasons, so they can update the database. It would be
> MUCH easier when they simply could read the bounces themselves.
>
>>> Now I forward the mail to an email on their mail server where it arrives,
>>> but
>>> later it gets lost somewhere when internal distribution is done.
>>> Probably a mailinglist dropping bounces or something alike.
>>>
>>> I'd like to know if there is an easy way in my postfix instance to
>>> encapsulate the bounce mails (or any email) I get into new mails of
>>> my own containing the bounce and maybe a simple text like "E-Mail
>>> delivery issue for ...", so it is no longer a normal bounce, but a
>>> normal email?
>>
>>
>> If you must do this, hold your nose and pipe the bounce to formail.
>
>
> Sorry, but that sentence does not help me to understand what needs to be
> done at all.
>
>> Or get a better provider.
>
>
> What provider?

I have a similar situation. I wrote a script which spots the relevant
bounce message in the mail log, from this it extracts the queue-id and
uses this to identify the copy of the original email saved in the
temporary local mailbox (which saves all mails passing through the
server). It extracts this email from there and forwards it as an
attachment to the relevant person using s-nail, with an explanatory
cover message. The same approach might work for you.

Re: Simple (attempted) AUTH logging?

[Dominic Raferd]

On 25/02/2017 05:28, Noel Jones wrote:

On 2/24/2017 5:55 PM, James wrote:

Current versions of postfix will log that AUTH was attempted, but do
not log what the client sends.  You can grep the logs for 'auth=0'
to see unsuccessful auth attempts.

postfix/smtpd[58629]: disconnect from unknown[192.168.0.33] ehlo=1
auth=0/1 commands=1/2

   -- Noel Jones

I was hoping there might be some setting that would cause log
entries like:

postfix/smtpd[12345]: NOQUEUE: AUTH rejected from
client.example.com[0.1.2.3], sasl_method=PLAIN, sasl_username=spam_r_us

As long as the sasl_username was obviously hopeless then I wouldn't
worry... but if they started using something that I thought they
shouldn't know about then I'd start getting worried.


I'm pretty sure the sasl_username part of the log (and probably the
method too) is supplied by the sasl library, which is never called
when sasl isn't offered.

When sasl isn't offered but the client sends AUTH anyway, it should
be possible for postfix to log the (sanitized) AUTH command the
client sends, but it will be encoded.  The encoding as recorded in
the log may be (I think likely) broken by the log sanitizer.

My impression is this won't be as useful as you hope. Or my analysis
could be flawed.

Maybe Wietse or others has something to add.


If you use dovecot for SASL authentication with settings log_path = 
syslog, auth_verbose = yes, then you can see attempted logins and the 
reason for failure easily enough:


# grep "dovecot: auth: " /var/log/mail.log

2017-02-17 13:17:03 vps344433 dovecot: auth: 
passwd-file(test,211.110.17.172): unknown user (SHA1 of given password: 
a94a8fe5ccb19ba61c4c0873d391e987982fbbd3)


2017-02-17 13:17:14 vps344433 dovecot: auth: 
passwd-file(test,211.110.17.172): unknown user (SHA1 of given password: 
5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8)


2017-02-17 13:17:29 vps344433 dovecot: auth: 
passwd-file(test,211.110.17.172): unknown user (SHA1 of given password: 
7c4a8d09ca3762af61e59520943dc26494f8941b)


2017-02-17 13:19:27 vps344433 dovecot: auth: Warning: auth client 0 
disconnected with 1 pending requests: Connection reset by peer

Re: dovecot cram-md5 setting break sending emails

[Dominic Raferd]

  
  
On 23/02/2017 09:06, Poliman - Serwis wrote:

  I also turned on verbose log in dovecot and below
is output in mail.log:
Feb 23 10:03:51 vps342401 postfix/smtps/smtpd[3640]:
xsasl_dovecot_server_connect: auth reply: DONE
Feb 23 10:03:51 vps342401 postfix/smtps/smtpd[3640]:
xsasl_dovecot_server_mech_filter: skip mechanism: PLAIN
Feb 23 10:03:51 vps342401 postfix/smtps/smtpd[3640]:
xsasl_dovecot_server_mech_filter: skip mechanism: LOGIN
Feb 23 10:03:51 vps342401 postfix/smtps/smtpd[3640]: fatal: no
SASL authentication mechanisms
Feb 23 10:03:52 vps342401 postfix/master[25124]: warning:
process /usr/lib/postfix/smtpd pid 3640 exit status 1
Feb 23 10:03:52 vps342401 postfix/master[25124]: warning:
/usr/lib/postfix/smtpd: bad command startup -- throttling
Feb 23 10:04:12 vps342401 postfix/anvil[3328]: statistics: max
connection rate 27/60s for (submission:54.175.125.239) at Feb 23
09:58:20
Feb 23 10:04:12 vps342401 postfix/anvil[3328]: statistics: max
connection count 1 for (submission:54.175.125.239) at Feb 23
09:58:08
Feb 23 10:04:12 vps342401 postfix/anvil[3328]: statistics: max
message rate 1/60s for (smtps:93.X.X.31) at Feb 23 10:00:37
Feb 23 10:04:12 vps342401 postfix/anvil[3328]: statistics: max
cache size 3 at Feb 23 09:58:21
  


These seem to be from postfix, not from dovecot. You
  can get more info from dovecot by enabling debug_log_path =
  path/to/debug/log and by ensuring that the changes you've made to
  the configuration are actually seen by dovecot. The easiest way to
  verify what dovecot is actually using at runtime is the doveconf
  command, dovecot -a will show you these values. Are you using
  fail2ban? (suggestions cribbed from
http://serverfault.com/questions/588391/how-to-get-doveconf-to-reload-its-config-or-read-from-etc-dovecot)
  

Re: dovecot cram-md5 setting break sending emails

[Dominic Raferd]

On 23 February 2017 at 07:01, Poliman - Serwis  wrote:
> ...
> All worked fine. Then I added in dovecot.conf file:
> auth_mechanisms = plain login cram-md5 #added cram-md5
>
> passdb {
>   #args = /etc/dovecot/dovecot-sql.conf
>   #driver = sql
>driver = passwd-file
>args = scheme=cram-md5 /etc/dovecot/cram-md5.pwd
> }
>
> In passdb block commented out default lines and add two (I can put whole
> dovecot config). All things still worked fine. Then - in dovecot.conf file I
> changed back setting to default. After this I can't send emails. In log I
> have:
> Feb 23 06:46:49 vps301 postfix/smtps/smtpd[24919]: fatal: no SASL
> authentication mechanisms
> Feb 23 06:47:50 vps301 postfix/smtps/smtpd[24942]: fatal: no SASL
> authentication mechanisms

I suspect it is not permitted to have # comments in dovecot conf files
except on a line of their own, though I admit I can't find this
documented. Try removing '#added cram-md5' or putting it on a line of
its own.

Re: postfix access map

[Dominic Raferd]

On 20 February 2017 at 07:58, Admin Beckspaced  wrote:

> Dear Postfix users,
>
> First a belated BIG THANK YOU to Wietse and his 20 years of Postfix.
> You're awesome!
>
> Second:
>
> I'm running Postfix version 2.11.6 and have setup an access map of sender
> email addresses
>
> someu...@somedomain.com OK
>
> then doing a postmap on the access map and in the main.cf I setup the
> following:
>
> smtpd_sender_restrictions =
> ​​
> hash:/etc/postfix/access
>
> and later in the main.cf I setup some recipient restrictions with checks
> on RBL
>
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated,
> ...
> reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org,
> ...
> permit
>
> Now I thought whenever I got an email from a sender listed in the access
> map it will always get delivered, because of the OK action, and will skip
> checks in the smtpd_recipient_restrictions?
>
> but today a customer send me the following:
>
> From: Mail Delivery System
> Sent: Sunday, February 19, 2017 10:22 AM
> To: someu...@somedomain.com
> Subject: Undelivered Mail Returned to Sender
>
> This is the mail system at host mailout04.t-online.de.
>
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to postmaster.
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
>   The mail system
>
> : host mail.beckspaced.com[78.46.161.3] said: 554
> 5.7.1
>Service unavailable; Client host [194.25.134.18] blocked using
>bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtm
> l?194.25.134.18
>(in reply to RCPT TO command)
>
> and the sender was the email address listed in the access map.
>
> So I thought that email in the access map will never make it to the RBL
> checks and always will pass as OK?
>
> Is there anything I need to think of to make it work? Whitelist an email
> address to always get accepted?
>

An 'OK' in your access file only causes emails which match it to skip
further tests that occur in the one restriction list in which you have
mentioned it i.e. sender_restrictions. It doesn't affect the separate
restriction list 'recipient_restrictions' in which you have your RBLs (or
any other restriction lists). The solution is to duplicate or move
hash:/etc/postfix/access to being inside recipient_restrictions but above
your RBL checks.

Re: Different treatment of ports 465 and 587 between postfix versions 2.9 and 3.1

[Dominic Raferd]

On 17 February 2017 at 19:38, Fazzina, Angelo  wrote:
> Hi,
> I thought the master.cf file is where you config what protocol to listen for ?
>
> Submission  or SMTPS
>
> I'm no expert either, just curious what your setup is.
> -ALF
>
> -Angelo Fazzina
> Operating Systems Programmer / Analyst
> University of Connecticut,  UITS, SSG, Server Systems
> 860-486-9075
>
> -Original Message-
> From: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Chris Green
> Sent: Friday, February 17, 2017 10:43 AM
> To: postfix-users@postfix.org
> Subject: Different treatment of ports 465 and 587 between postfix versions 
> 2.9 and 3.1
>
> I am running postfix 3.1.0 on an xubuntu 16.04 system and postfix 2.9.6
> on a Raspberry Pi running Debian.
>
> They seem to act very differently as regards the use of ports 465 and
> 587 and I'd like things clarified so I can understand better.
>
> I use both postfix installations to send outgoing E-Mail (i.e. mail
> which is leaving my home LAN) to my hosting company's servers.  Their
> documentation says that I should use port 465 and TLS to connect to
> the SMTP server.
>
> ...
> Ah, I've maybe just spotted the reason, smtp_tls_wrappermode is new in
> postfix 3, is that what makes the difference?  I'd still like a simple
> explanation though!  :-)

see http://www.postfix.org/TLS_README.html#client_smtps
- use stunnel for postfix <3.0 (it still works for postfix >=3.0)

Re: Strong Ciphers to use with Postfix

[Dominic Raferd]

On 17 February 2017 at 14:43, Fazzina, Angelo  wrote:
> Hi,
> Here is how I am dealing with "weak ciphers"
> You may be able to do the same type of config ?
>
>
> In /etc/postfix/main.cf
>
>
> # -ALF 2016-09-07
> # disable RC4 ciphers with TLS connections.
> #smtpd_tls_exclude_ciphers = RC4, aNULL
> # -ALF 2017-01-09
> # disable weak ciphers, and RC4 ciphers
> smtpd_tls_exclude_ciphers = DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, RC4, aNULL
> #-ALF 2107-01-09
> # disable SWEET32 ciphers, weak ciphers, and RC4 ciphers
> #smtpd_tls_exclude_ciphers = IDEA-CBC-SHA, DES-CBC3-SHA, 
> EDH-RSA-DES-CBC3-SHA, RC4, aNULL
>
>
>
> -Angelo Fazzina
> Operating Systems Programmer / Analyst
> University of Connecticut,  UITS, SSG, Server Systems
> 860-486-9075
>
> -Original Message-
> From: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Daniel Bareiro
> Sent: Friday, February 17, 2017 9:40 AM
> To: Postfix users 
> Subject: Strong Ciphers to use with Postfix
>
> Hi all!
>
> I'm using Debian GNU/Linux Jessie 8.7 with Postfix 2.11.3-1.
>
> I would like to know what you think of the security settings suggested
> here [1] for Postfix.
>
> I have tested it against this [2] site, but it seems that fails to
> discard other ciphers; on "Weak ciphers" I get "supported
> RSA_WITH_RC4_128_SHA".
>

As I have learned from here, if your MTA is receiving from the world
or sending to the world there is little point in enforcing
super-strong ciphers on the corresponding connection (smtpd or smtp).
If you refuse all unencrypted communication, and only permit
super-strong ciphers, you may not be able to receive or send some
emails, because not all (even genuine) MTAs will support this; but
otherwise if you only permit super-strong ciphers you will just get
more unencrypted communication. Of course it is usually
pointless/unwise to permit broken ciphers, but these are anyway
disabled by default in postfix.

Re: Which domain and host in main.cf

[Dominic Raferd]

On 15 February 2017 at 10:51, Henry  wrote:
> When reading through main.cf and configuring postfix I am unsure of
> which domain, origin and hostname values to use.
>
> For example say our public domain is mydomain.com and we have a
> certificate for mail.mydomain.com and our MX points to
> mail.mydomain.com
>
> Our mail server called hermes runs our our lan who'se domain is mydomain.local
>
> In main.cf is:
> myorigin hermes.mydomain.local or mail.mydomain.com
> myhostname hermes or mai
> dydoman mydomain.local or mydomain.com
>

I have a certificate for mydomain.tld (not for mail1.mydomain.tld) and
use as follows:
mydomain = mydomain.tld
myorigin = $mydomain
myhostname: hard coded to valid external fqdn for this machine - not
necessarily the reverse fqdn e.g. mail1.mydomain.tld
smtpd_banner: hard coded to the reverse fqdn for this machine as given
by, for instance: dig +short -x $(dig +short myip.opendns.com
@resolver1.opendns.com)

It doesn't matter that the certificate is not for the fqdn or reverse
fqdn of your server, but I think it is good that the server's
announced name is its real reverse fqdn, some senders might check
this.

Re: SSL Certificates

[Dominic Raferd]

On 15 February 2017 at 09:34, Alice Wonder  wrote:
> On 02/15/2017 12:32 AM, Dominic Raferd wrote:
>>
>> On 15 February 2017 at 07:58, Richard James Salts
>>  wrote:
>>>
>>>
>>>
>>> On 15 February 2017 6:47:31 PM AEDT, Viktor Dukhovni
>>>  wrote:
>>>>
>>>>
>>>> Please do not encourage novice users to configure DMARC.  This does
>>>> much
>>>> more harm than good.  DMARC is legitimately for the few likePayPal,
>>>> abusively
>>>> for too big to fail like Yahoo
>>>
>>>
>>
>> Viktor, off topic perhaps but I am interested in your downer on DMARC.
>> As I understand it, the point of DMARC is to prevent others from
>> sending fake mails that purport to come from 'me' or 'my' domain. I am
>> responsible for a few low-volume domains but this has happened to us,
>> as it probably has to most others. The global email system surely
>> needs a way to verify that emails are really from the purported sender
>> and that they have not been altered on their way to their intended
>> recipient, and DMARC (with DKIM, and not using p=none) offers this.
>> Are there better alternatives?
>>
>
> I'm not Viktor but I'll answer.
>
> I run DMARC on one domain just as a test and find it useless. The problem is
> mail lists, a lot of mail lists don't handle things correctly resulting in
> one message to a list resulting in a ton of failure reports.
>
> For me, DMARC is one of those things that sounds good but in practice
> doesn't really work.
>
> Now PayPal - they usually don't send to mail lists so the problem I
> experience may not exist for them, but for me, it seems useless. Way way way
> too many false positives caused my mail lists.
>
> I do run SPIF and DKIM however. The thought is that if someone is sending
> fraudulent mail on behalf of my domain, failing those will increase the odds
> that it gets flagged by spam filters.
>
> I don't know how often that happens, it seems very rare that someone sends a
> message claiming to be from my domain and when they do, it usually is from
> my domain to my domain and it does get caught (e.g. fake mail from
> sales@whatever to admin@whatever or vice versa) by my spam filters. DMARC
> isn't needed to catch those though.

Thanks for your answer.

There may be a problem between DMARC and mailing lists - I avoid
p=reject or p=quarantine on domains I use for posting to mailing
lists.

SPF proves sender identity but final recipient MTA cannot rely on it
if there are any intermediate relaying servers between it and the
originating MTA; so while SPF=pass proves sender identity, SPF=fail
proves nothing. DKIM proves content and/or header integrity but not
sender identity (false DKIM can be injected - see
http://www.zdnet.com/article/dkim-useless-or-just-disappointing/).
DMARC uses alignment to prove identity *and* integrity; it is a
solution to a fundamental problem, as I understand it.

Re: SSL Certificates

[Dominic Raferd]

On 15 February 2017 at 07:58, Richard James Salts
 wrote:
>
>
> On 15 February 2017 6:47:31 PM AEDT, Viktor Dukhovni 
>  wrote:
>>
>>Please do not encourage novice users to configure DMARC.  This does
>>much
>>more harm than good.  DMARC is legitimately for the few likePayPal,
>>abusively
>>for too big to fail like Yahoo
>

Viktor, off topic perhaps but I am interested in your downer on DMARC.
As I understand it, the point of DMARC is to prevent others from
sending fake mails that purport to come from 'me' or 'my' domain. I am
responsible for a few low-volume domains but this has happened to us,
as it probably has to most others. The global email system surely
needs a way to verify that emails are really from the purported sender
and that they have not been altered on their way to their intended
recipient, and DMARC (with DKIM, and not using p=none) offers this.
Are there better alternatives?