Re: G Suite mx checker complains "do not configure the mail service on the only domain name."

[Poliman - Serwis]

2018-11-14 10:22 GMT+01:00 Håkon Alstadheim :

>
> Den 14.11.2018 08:21, skrev Poliman - Serwis:
>
>>
>>
>> 2018-11-13 19:58 GMT+01:00 Wietse Venema > wie...@porcupine.org>>:
>>
>> Poliman - Serwis:
>> > 2018-11-13 18:24 GMT+01:00 Viktor Dukhovni <
>> postfix-us...@dukhovni.org
>> >:
>> >
>> > > > On Nov 13, 2018, at 11:48 AM, Wietse Venema
>> mailto:wie...@porcupine.org>>
>> > > wrote:
>> > > >
>> > > >> It's colonel.com.pl . Please check.
>> I don't see anywhere MX's IP as A
>> > > record
>> > > >> in dns zone.
>> > > >
>> > > > You have both A and MX records for colonel.com.pl
>> . Some SMTP systems
>> > > > may try to send email using the A record, if those SMTP
>> systems are
>> > > > borked and if their DNS resolver is borked.
>> > >
>> > > In other words, nothing to worry about. There's no need to
>> worry about
>> > > such broken systems in practice.  Real MTAs don't get this
>> wrong (though
>> > > perhaps what I'm saying is that if there are some MTAs that
>> get this wrong,
>> > > they are garbage that deserves to be ignored).
>> > >
>> > > --
>> > > Viktor.
>> > >
>> > > [1] https://en.wikipedia.org/wiki/Infinite_monkey_theorem
>> 
>> >
>> >
>> > Ok, thank you guys for answers and advices. Appreciate!
>>
>> You man still want to turn off the SMTP listener on colonel.com.pl
>> ,
>> because it will never receive legitimate email.
>>
>> Wietse
>>
>>
>> Thank you for answer. I suppose I don't understand properly. How could I
>> do this if this domain has MX on Google?
>>
>> To make sure all mail delivered to colonel.com.pl gets to google, make
> sure that the host colonel.com.pl will NOT accept connections for
> incoming mail from the internet.
>
> In other words: if you want mail to end up at your MX, your A ip-address
> should not accept incoming mail.
>
> If that is already OK, you are OK. It looks OK from where I am sitting.
>
> Viz:
>
> # dig colonel.com.pl mx
>
> ; <<>> DiG 9.11.2-P1 <<>> colonel.com.pl mx
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63690
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 2, ADDITIONAL: 3
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;colonel.com.pl.IN  MX
>
> ;; ANSWER SECTION:
> colonel.com.pl. 3600IN  MX  5 alt1.aspmx.l.google.com.
> colonel.com.pl. 3600IN  MX  5 alt2.aspmx.l.google.com.
> colonel.com.pl. 3600IN  MX  10 alt4.aspmx.l.google.com
> .
> colonel.com.pl. 3600IN  MX  10 alt3.aspmx.l.google.com
> .
> colonel.com.pl. 3600IN  MX  1 aspmx.l.google.com.
>
> ;; AUTHORITY SECTION:
> colonel.com.pl. 3576IN  NS  ns6.poliman.net.
> colonel.com.pl. 3576IN  NS  ns7.poliman.net.
>
> ;; ADDITIONAL SECTION:
> ns6.poliman.net.3576IN  A   193.70.38.6
> ns7.poliman.net.3576IN  A   54.38.202.128
>
> ;; Query time: 42 msec
> ;; SERVER: 192.168.2.2#53(192.168.2.2)
> ;; WHEN: on. nov. 14 10:20:30 CET 2018
> ;; MSG SIZE  rcvd: 240
>
> 0:gt ~ # nc colonel.com.pl 25
> nc: unable to connect to address colonel.com.pl, service 25
>
>
> Really appreciate help. About " In other words: if you want mail to end up
at your MX, your A ip-address should not accept incoming mail. " -
currently I have spf which allow sending emails only for google servers
added as MX records (I have removed 'a' from spf record). Second - I tried
"nc colonel.com.pl 25" from virtual machine deployed on my PC in job and
result:
tot@haha:~# nc colonel.com.pl 25
220 s1.poliman.net ESMTP Postfix (Ubuntu)
^C



-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*

Re: G Suite mx checker complains "do not configure the mail service on the only domain name."

[Dominic Raferd]

On Thu, 15 Nov 2018 at 09:40, Poliman - Serwis  wrote:

> Really appreciate help. About " In other words: if you want mail to end up
> at your MX, your A ip-address should not accept incoming mail. " -
> currently I have spf which allow sending emails only for google servers
> added as MX records (I have removed 'a' from spf record). Second - I tried
> "nc colonel.com.pl 25" from virtual machine deployed on my PC in job and
> result:
> tot@haha:~# nc colonel.com.pl 25
> 220 s1.poliman.net ESMTP Postfix (Ubuntu)
>

So you are running a receiving postfix mail server on the A ip-address of
colonel.com.pl. What for? G-Suite does it all for you, you shouldn't be
using any other relaying mail server - just send and receive through Gmail.

If you still want to run postfix for outgoing mail on the machine which is
receiving colonel.com.pl:25,  you can stop postfix processing incoming mail
there with:
postconf inet_interfaces=loopback-only

Re: G Suite mx checker complains "do not configure the mail service on the only domain name."

[Poliman - Serwis]

2018-11-15 12:14 GMT+01:00 Dominic Raferd :

> On Thu, 15 Nov 2018 at 09:40, Poliman - Serwis  wrote:
>
>> Really appreciate help. About " In other words: if you want mail to end
>> up at your MX, your A ip-address should not accept incoming mail. " -
>> currently I have spf which allow sending emails only for google servers
>> added as MX records (I have removed 'a' from spf record). Second - I tried
>> "nc colonel.com.pl 25" from virtual machine deployed on my PC in job and
>> result:
>> tot@haha:~# nc colonel.com.pl 25
>> 220 s1.poliman.net ESMTP Postfix (Ubuntu)
>>
>
> So you are running a receiving postfix mail server on the A ip-address of
> colonel.com.pl. What for? G-Suite does it all for you, you shouldn't be
> using any other relaying mail server - just send and receive through Gmail.
>
> If you still want to run postfix for outgoing mail on the machine which is
> receiving colonel.com.pl:25,  you can stop postfix processing incoming
> mail there with:
> postconf inet_interfaces=loopback-only
>

I have few domains on the server. Some part of them use my server for send
emails but few have configured external mail service like Google. I need to
disable using my mail service by colonel.com.pl on my server. There need to
be only google, nothing more but other domains need to use my mail service.

-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*

OT: features / test criteria for email filtering/security product

[Roger Goh]

I'm looking at Votiro, Proofpoint & Israel email security products
to reduce spam, emails from bad reputation IP, emails with
malicious attachments & URL.

What are the features/criteria to assess or look out for?

Esp if I'm on O365.

a) can link to SpamHaus, RBL etc to get bad reputation IP?
b) offers CDR, sandboxing?
c) can claw back malicious emails from users' mailbox once
Sandboxing completed analysis that an email or attachmt
is malicious (Proofpoint has one such  product)
d) can withstand email blasting (eg: 8/minute)
e) ... help add on ...

Re: G Suite mx checker complains "do not configure the mail service on the only domain name."

[B. Reino]

On 2018-11-15 12:24, Poliman - Serwis wrote:

I have few domains on the server. Some part of them use my server for 
send emails but few have
configured external mail service like Google. I need to disable using 
my mail service by
colonel.com.pl on my server. There need to be only google, nothing more 
but other domains need

to use my mail service.


Well then just leave it as it is. Obviously the warning you got from 
Google does not apply, because that SMTP server is taking care of other, 
unrelated, domains. Therefore you can safely ignore the warning, as it 
is wrong.

Re: RFE: DANE functions + log

[Viktor Dukhovni]

> On Nov 15, 2018, at 10:32 AM, J. Thomsen  wrote:
> 
> 1) logging
> 
> More informative logging of what is happening, when smtp is trying to 
> establish a TLS connection
> using dane e.g. on dns lookups, TLSA lookups and the results

Please be more specific.  What exactly would you like to see logged,
perhaps with a suggested format.

See the posttls-finger(1) manpage, do any of the fine-grained
(-L logopts) logging features there do what you need?

   http://www.postfix.org/posttls-finger.1.html

> Better documentation of what is actually meant by these messages:
> 
> Anonymous TLS connection established
> Trusted TLS connection established
> Verified TLS connection established

http://www.postfix.org/FORWARD_SECRECY_README.html#status

> 2) problem with no ad flag when the resolver is querying an authoritative DNS
> 
> In this case Postfix is running on the same server as the authoritative 
> server and using it as a
> recursive resolver. I had to change the resolv.conf file to an external DNS, 
> but for various reasons
> this will not work properly in all cases.

The simplest advice is split the authoritative and recursive services.
I have authoritative servicing the machine's public IP, and the recursive
servicing only 127.0.0.1 and ::1.  Separating authoritative and recursive
services is good for many reasons, not just Postfix's use of the AD bit.

> This issue should be solved, and at least be mentioned in the documentation
> for DANE, as it can be a showstopper.

Yes, a comprehensive DANE_README document is needed.

> 3) TLS SNI
> 
> The documentation states, that there are no plans to implement SNI in the 
> Postfix
> SMTP server.  Is this still valid? 

No, SNI support is under development.

-- 
Viktor.

Re: Performing rcpt_verification based on sender possible?

[Tobi]

Noel,

omg own stupidity :-)
Settings all are okay but there was a cache file for results of verify
lookups.
Forgot that I changed the rcpt test account to REJECT within the last
31days (default for address_verify_positive_expire_time)

So instead of waiting for max 31days for the "postfix self-healing" to
kick in ;-), I removed the file and postfix reload and it works

Thanks a lot for your help and have a good one

tobi

Am 14.11.18 um 16:29 schrieb Noel Jones:
> On 11/14/2018 2:50 AM, Tobi wrote:
> 
>>
>> $ postconf -d|grep parent_domain_matches
>> parent_domain_matches_subdomains =
>> debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps
>>
> 
> caution: "postconf -d" shows the compiled-in defaults, not current
> settings.  use "postconf" (no options) to show current settings.
> 
> 
>> Will set postfix to debug as described this evening and see if I can get
>> more information about this issue.
> 
> No, setting postfix to debug was not recommended.  The combination
> of "postconf -n" plus any overrides you've added in master.cf, and
> normal logging almost certainly provides all the information you
> need.  Debug logging will likely bury the real problem in a flood of
> unrelated information.
> 
> 
>   -- Noel Jones
> 

Postscreen usually rejects based on DNSBLs. Good enough? Lower overhead options?

[pg151]

I see countless Postscreen rejections of this type

Nov 14 13:28:58 mx postfix/postscreen[11068]: CONNECT from 
[86.49.239.233]:19243 to [#.#.#.#]:25
Nov 14 13:28:58 mx postfix/dnsblog[11069]: addr 86.49.239.233 listed by 
domain bl.spamcop.net as 127.0.0.2
Nov 14 13:28:58 mx postfix/dnsblog[11072]: addr 86.49.239.233 listed by 
domain zen.spamhaus.org as 127.0.0.4
Nov 14 13:28:58 mx postfix/dnsblog[11071]: addr 86.49.239.233 listed by 
domain bl.mailspike.net as 127.0.0.10
Nov 14 13:29:04 mx postfix/postscreen[11068]: DNSBL rank 9 for 
[86.49.239.233]:19243
Nov 14 13:29:05 mx postfix/postscreen[11068]: NOQUEUE: reject: RCPT 
from [86.49.239.233]:19243: 550 5.7.1 Service unavailable; client 
[86.49.239.233] blocked using Spamhaus; from=, 
to=, proto=ESMTP, helo=
Nov 14 13:29:05 mx postfix/postscreen[11068]: HANGUP after 0.9 from 
[86.49.239.233]:19243 in tests after SMTP handshake
Nov 14 13:29:05 mx postfix/postscreen[11068]: DISCONNECT 
[86.49.239.233]:19243

Postscreen is clearly doing its job of fending these off.

I'm interested in the expense of that rejection.

Its ~always based on a DNSBL rejection.

Is it efficient (enough) to check the DNSBLs I've got configured for postscreen?

That email is

from=
to=

Obviously spam.

I do have DMARC policy, DKIM & SPF record configured for my domain.

Are any of those, or the 'me-to-me' attempt, "cheaper"?  If so, is it possible 
to promote their use in Postscreen?

Or is postscreen already at low(est) overhead, and best to leave it as is?

I suspect the answer is yes.

Re: Postscreen usually rejects based on DNSBLs. Good enough? Lower overhead options?

[Viktor Dukhovni]

> On Nov 15, 2018, at 9:34 PM, pg...@dev-mail.net wrote:
> 
> Is it efficient (enough) to check the DNSBLs I've got configured for 
> postscreen?

Yes.

> That email is
> 
>   from=
>   to=
> 
> I do have DMARC policy, DKIM & SPF record configured for my domain.
> 
> Are any of those, or the 'me-to-me' attempt, "cheaper"?

No.  Because postscreen(8) does (typically all) its work on TCP connect, before 
any
SMTP dialogue takes place.  To the see the from/to addresses you'd have to talk 
to
an actual smtpd(8) to handle the mail transaction, which is what postscreen(8) 
is there
to avoid.

> If so, is it possible to promote their use in Postscreen?

No.

> Or is postscreen already at low(est) overhead, and best to leave it as is?

Leave it be.

-- 
Viktor.

Re: Postscreen usually rejects based on DNSBLs. Good enough? Lower overhead options?

[Benny Pedersen]

pg...@dev-mail.net skrev den 2018-11-16 03:34:


Postscreen is clearly doing its job of fending these off.


it works as designed


from=
to=


begin blocking this with reject local recipient as senders, or block it 
with spf testing

Rejecting based on From is...not rejecting

[Dennis Carr]

Heya. Postfix 3.1.8 on Debian Stable.

I'm trying to use /etc/postfix/sender_access to pretty much reject
anything showing as 'From: *@qq.com' as there's a plethora of spam
coming from that domain - and it's not rejecting.  Suffice it to say, I
seem to be doing it wrong.

In sender_access, I have:

\/.qq.com$/ REJECT

...and the reference to this file in main.cf is:

smtpd_sender_restrictions =
check_sender_access  hash:/etc/postfix/sender_access,
...

...what'd I miss?  

If needed I can stick the files up on a pastebin.

-Dennis Carr

Re: Rejecting based on From is...not rejecting

[Viktor Dukhovni]

> On Nov 16, 2018, at 12:17 AM, Dennis Carr  
> wrote:
> 
> I'm trying to use /etc/postfix/sender_access to pretty much reject
> anything showing as 'From: *@qq.com'

Postfix access(5) tables restrict the message envelope, not the message headers.

> Suffice it to say, I seem to be doing it wrong.

In a creatively diverse number of ways. :-)

> In sender_access, I have:
> 
> \/.qq.com$/ REJECT

If were supposed to be a regular expression table, it would be:

/\.qq\.com$/REJECT

But there's no need to use regular expressions to match literal domain names.
You'd use a "cdb" or "hash" table for something so simple, with literal keys:

qq.com  REJECT

> ...and the reference to this file in main.cf is:
> 
> smtpd_sender_restrictions =
>check_sender_access  hash:/etc/postfix/sender_access,
>   ...

And so you are, but you're using regular expression syntax, that's
broken while you're at it.

> ...what'd I miss?  

Well, everything really.

> If needed I can stick the files up on a pastebin.

No need.

-- 
Viktor.

Re: Rejecting based on From is...not rejecting

[Dominic Raferd]

On Fri, 16 Nov 2018 at 05:18, Dennis Carr 
wrote:

> Heya. Postfix 3.1.8 on Debian Stable.
>
> I'm trying to use /etc/postfix/sender_access to pretty much reject
> anything showing as 'From: *@qq.com' as there's a plethora of spam
> coming from that domain - and it's not rejecting.  Suffice it to say, I
> seem to be doing it wrong.
>
> In sender_access, I have:
>
> \/.qq.com$/ REJECT
>
> ...and the reference to this file in main.cf is:
>
> smtpd_sender_restrictions =
> check_sender_access  hash:/etc/postfix/sender_access,
> ...
>
> ...what'd I miss?
>
> If needed I can stick the files up on a pastebin.
>

I'm afraid there are several mistakes here:
- you say you want to ban based on the 'From:' address which if true would
require you to use header_checks (
http://www.postfix.org/header_checks.5.html) not sender_access
- you are using a 'hash' table in main.cf but have put regex (or pcre)
format in your table
- the regex contains errors

I think you actually want to reject based on the envelope sender (not From
header), in which case you want main.cf unchanged and sender_access like:
qq.com REJECT

Then do 'postmap /etc/postfix/sender_access' to create the sender_access.db
file which is what postfix will be looking for.

Re: Rejecting based on From is...not rejecting

[Dennis Carr]

On Fri, 16 Nov 2018 01:08:42 -0500
Viktor Dukhovni  wrote:

> On Nov 16, 2018, at 12:17 AM, Dennis Carr
>  wrote:
> 
> > Suffice it to say, I seem to be doing it wrong.
> 
> In a creatively diverse number of ways. :-)
 
Well Viktor, we can't say I do everything right, now, can we? =D

I noted too in Dominic's response the pointer to header_checks instead;
sounds like the better option.  I'll give that a go.

-Dennis Carr

Re: Rejecting based on From is...not rejecting

[Dominic Raferd]

On Fri, 16 Nov 2018 at 06:49, Dennis Carr 
wrote:

> On Fri, 16 Nov 2018 06:10:28 +
> Dominic Raferd  wrote:
>
> > - you say you want to ban based on the 'From:' address which if true
> > would require you to use header_checks (
> > http://www.postfix.org/header_checks.5.html) not sender_access
>
> That'd work better, then.
>
> > I think you actually want to reject based on the envelope sender (not
> > From header), in which case you want main.cf unchanged and
> > sender_access like: qq.com REJECT
>
> Here's the thing, it's a spam campaign where emails from qq.com are
> coming from what appears to be a few different IP blocks on two
> different providers and cycling through the IPs as to dodge
> blacklisting, as well as randomizing their FQDNs - so in this case, I
> don't think scanning the envelope is going to work unless there's
> something I'm missing.  I've tried contacting the providers' upstream,
> but the upstream doesn't seem to listen either - at least, not if I
> send a third party report from Spamcop.
>
> The ONLY other common thing is that everything is 'From: *@qq.com' in
> the headers. I could probably figure out the IP ranges, but that
> opens the possibility of changing the IP ranges if the providers are
> so flexible - and I'd be patient with the BLs, but this is affecting
> users.
>

The reason I think you actually want to reject based on the envelope sender
is because I too see lots of attempted spam from @qq.com envelope sender
addresses. On our servers these are blocked by fqrdns (
https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre). I can't
tell what the 'From' header is because they are all blocked before data is
sent. Blocking by sender (or using fqrdns) is much cheaper than blocking by
header.

Re: G Suite mx checker complains "do not configure the mail service on the only domain name."

[Poliman - Serwis]

2018-11-15 15:19 GMT+01:00 B. Reino :

> On 2018-11-15 12:24, Poliman - Serwis wrote:
>
> I have few domains on the server. Some part of them use my server for send
>> emails but few have
>> configured external mail service like Google. I need to disable using my
>> mail service by
>> colonel.com.pl on my server. There need to be only google, nothing more
>> but other domains need
>> to use my mail service.
>>
>
> Well then just leave it as it is. Obviously the warning you got from
> Google does not apply, because that SMTP server is taking care of other,
> unrelated, domains. Therefore you can safely ignore the warning, as it is
> wrong.
>

Ok, thank you.

-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*