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

[Poliman - Serwis]

2018-11-13 19:58 GMT+01:00 Wietse Venema :

> Poliman - Serwis:
> > 2018-11-13 18:24 GMT+01:00 Viktor Dukhovni :
> >
> > > > On Nov 13, 2018, at 11:48 AM, Wietse Venema 
> > > 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?

-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*

Re: looking for any options to better deal with mail looping

[Viktor Dukhovni]

> On Nov 13, 2018, at 4:22 PM, Fazzina, Angelo  wrote:
> 
> Is it as simple as changing this parameter in main.cf ?
> unverified_recipient_defer_code (default: 450)

Yes.

-- 
Viktor.

RE: looking for any options to better deal with mail looping

[Fazzina, Angelo]

Hi, thank you Viktor, i deleted the .db file. 
i reread the docs and removed all my previous changes and started over.

Wietse, thanks for the tip "relay_recipient_maps"

My old config was :

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_unauth_destination

transport_maps = hash:/etc/postfix/maps/transport
/etc/postfix/maps/transport .
darwin.eeb.uconn.edusmtp:[darwin.eeb.uconn.edu]

My new config is :

smtpd_recipient_restrictions = reject_unknown_recipient_domain, 
reject_unverified_recipient, permit_mynetworks, permit_sasl_auth
enticated, reject_unauth_destination

relay_recipient_maps =  mysql:/etc/postfix/files/mysql_pn.cf

the transport stuff was left untouched.

RAN  systemctl reload postfix
tested 
[root@mta4 postfix]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mta4.uits.uconn.edu ESMTP Postfix (2.10.1)
ehlo uconn.edu
250-mta4.uits.uconn.edu
250-PIPELINING
250-SIZE 31457280
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from:ang...@uconn.edu
250 2.1.0 Ok
rcpt to:ang...@darwin.eeb.uconn.edu
450 4.1.1 : Recipient address rejected: unverified 
address: host darwin.eeb.uconn.edu[137.99.139.139] said: 550 5.1.1 
: Recipient address rejected: User unknown in 
local recipient table (in reply to RCPT TO command)
rcpt to:k...@darwin.eeb.uconn.edu
250 2.1.5 Ok
quit
221 2.0.0 Bye

I think it's working as desired, only one thing I can't understand.
My server mta4 gave the 450 4.1.1 and server Darwin.eeb.uconn.edu gave 550 
5.1.1, so why is it taking so long to get an NDR ?

[ I did another test with my outlook client and got same response  as seen here 
from O365 message trace details]
Reason: [{LED=450 4.1.1 : Recipient address 
rejected: unverified address: host darwin.eeb.uconn.edu[137.99.139.139] said: 
550 5.1.1 : Recipient address rejected: User 
unknown in local recipient table (in reply to RCPT TO 
command)};{MSG=};{FQDN=smtp.uconn.edu};{IP=137.99. OutboundProxyTargetIP: 
137.99.25.243. OutboundProxyTargetHostName: smtp.uconn.edu

Is it as simple as changing this parameter in main.cf ?
unverified_recipient_defer_code (default: 450)


-ANGELO FAZZINA

ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

ang...@uconn.edu
University of Connecticut,  ITS, SSG, Server Systems
860-486-9075

-Original Message-
From: owner-postfix-us...@postfix.org  On 
Behalf Of Viktor Dukhovni
Sent: Wednesday, November 7, 2018 4:55 PM
To: postfix users 
Subject: Re: looking for any options to better deal with mail looping

> On Nov 7, 2018, at 3:26 PM, Fazzina, Angelo  wrote:
> 
> relay_recipient_maps =  mysql:/etc/postfix/files/mysql_pn.cf
> 
> I did a test
> postmap /etc/postfix/files/mysql_pn.cf

There's no point in trying to "postmap" MySQL, LDAP, PosgreSQL, "pcre", 
"regexp", ...
tables.

Only tables that have an on-disk *indexed* format need "postmap":

- cdb
- btree
- hash
- lmdb
- dbm  (obsolete)
- sdbm (obsolete)

-- 
Viktor.

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

[Wietse Venema]

Poliman - Serwis:
> 2018-11-13 18:24 GMT+01:00 Viktor Dukhovni :
> 
> > > On Nov 13, 2018, at 11:48 AM, Wietse Venema 
> > 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

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

[Poliman - Serwis]

2018-11-13 18:24 GMT+01:00 Viktor Dukhovni :

> > On Nov 13, 2018, at 11:48 AM, Wietse Venema 
> 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!

-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*

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

[Viktor Dukhovni]

> On Nov 13, 2018, at 11:48 AM, Wietse Venema  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

Re: Performing rcpt_verification based on sender possible?

[Noel Jones]

On 11/13/2018 10:46 AM, Tobi wrote:
>> Postfix supports what you've described. You must have made some
>> other mistake.
> 
> believe me that's what I thought first :-) But the only reason this
> would not fire is that a prior restriction already OK the mail. To test
> I commented all client restrictions and placed my check_sender access on
> (almost) top of sender_restrictions
> 
> smtpd_sender_restrictions = reject_unknown_sender_domain,
>  reject_non_fqdn_sender,
>  check_sender_access hash:/etc/postfix/do_callahead,
>  []
> 
> so the restriction is well before any restriction that could ACCEPT the
> mail.
> 
> postmap tells me that it gets the correct value from the map
> 
> $ postmap -q 'example.com' /etc/postfix/do_callahead
> reject_unverified_recipient
> 
> 
> 

Two things that come to mind...

you must have smtpd_delay_reject=yes

and parent_domain_matches_subdomains must contain smtpd_access_maps

 check your "postconf -n" output to make sure it shows what you expect.

If you have more trouble, please see
http://www.postfix.org/DEBUG_README.html#mail


  -- Noel Jones

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

[Bastian Blank]

On Tue, Nov 13, 2018 at 05:31:13PM +0100, Poliman - Serwis wrote:
> It's colonel.com.pl. Please check. I don't see anywhere MX's IP as A record
> in dns zone.

You missed that the point is called "There should not be a mail
exchanger set up on naked domain name."

Don't run an externally reachable SMTP server on colonel.com.pl.

| % nc colonel.com.pl 25   
| 220 s1.poliman.net ESMTP Postfix (Ubuntu)

Bastian

-- 
Men will always be men -- no matter where they are.
-- Harry Mudd, "Mudd's Women", stardate 1329.8

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

[Wietse Venema]

Poliman - Serwis:
> 2018-11-13 16:05 GMT+01:00 Kris Deugau :
> 
> > Poliman - Serwis wrote:
> >
> >> Hello. I have used G Suite MX checker available here
> >> https://toolbox.googleapps.com/apps/checkmx/
> >>
> >
> > This seems to be a Google-specific tester for domains hosted with Google,
> > so it's difficult to compare with random other domains.
> >
> > and I have message: "The address of the mail server in the domain record A
> >> can cause poorly visible and difficult to diagnose errors manifested by
> >> "disappearing" e-mails in the event of problems with the DNS server. This
> >> problem can be diagnosed by entering a command*telnet your.do.main
> >> 25*[..]". How can I resolve this?
> 
> 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.

Wietse

Re: Performing rcpt_verification based on sender possible?

[Tobi]

> Postfix supports what you've described. You must have made some
> other mistake.

believe me that's what I thought first :-) But the only reason this
would not fire is that a prior restriction already OK the mail. To test
I commented all client restrictions and placed my check_sender access on
(almost) top of sender_restrictions

smtpd_sender_restrictions = reject_unknown_sender_domain,
 reject_non_fqdn_sender,
 check_sender_access hash:/etc/postfix/do_callahead,
 []

so the restriction is well before any restriction that could ACCEPT the
mail.

postmap tells me that it gets the correct value from the map

$ postmap -q 'example.com' /etc/postfix/do_callahead
reject_unverified_recipient



Am 13.11.18 um 17:18 schrieb Noel Jones:
> On 11/13/2018 9:43 AM, Tobi wrote:
>> Hello list
>>
>> I'm trying to achieve that a certain sender (or sender domain) must have
>> the recipients verified. Thought that it could be done with a
>> restriction class:
>>
>> #main.cf
>> smtpd_restriction_classes = DO_CALLAHEAD
>> DO_CALLAHEAD = reject_unverified_recipient
>> smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/my.map
>>
>> #my.map
>> example.com  DO_CALLAHEAD
>>
>> But if I test with example.com sender on a remote rcpt that is rejected,
>> the msg is always accepted and a bounce has to be sent back to sender.
>> Which is what I'm trying to avoid for this particular sender with rcpt
>> verification.
>>
>> Is there a way to achieve that with postfix?
>>
>> Thanks for any idea
>>
>> tobi
>>
> 
> 
> Postfix supports what you've described. You must have made some
> other mistake.
> 
> You can simplify your config by not using a restriction class, which
> isn't required for this particular function.
> 
> # my.map
> example.com  reject_unverified_recipient
> 
> 
> 
> 
>   -- Noel Jones
> 

Performing rcpt_verification based on sender possible?

[Tobi]

Hello list

I'm trying to achieve that a certain sender (or sender domain) must have
the recipients verified. Thought that it could be done with a
restriction class:

#main.cf
smtpd_restriction_classes = DO_CALLAHEAD
DO_CALLAHEAD = reject_unverified_recipient
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/my.map

#my.map
example.com DO_CALLAHEAD

But if I test with example.com sender on a remote rcpt that is rejected,
the msg is always accepted and a bounce has to be sent back to sender.
Which is what I'm trying to avoid for this particular sender with rcpt
verification.

Is there a way to achieve that with postfix?

Thanks for any idea

tobi

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

[Kris Deugau]

Poliman - Serwis wrote:
Hello. I have used G Suite MX checker available here 
https://toolbox.googleapps.com/apps/checkmx/


This seems to be a Google-specific tester for domains hosted with 
Google, so it's difficult to compare with random other domains.


and I have message: "The 
address of the mail server in the domain record A can cause poorly 
visible and difficult to diagnose errors manifested by "disappearing" 
e-mails in the event of problems with the DNS server. This problem can 
be diagnosed by entering a command*telnet your.do.main 25*[..]". How can 
I resolve this?



It would be helpful to know which domain you're testing so the rest of 
us can read the entire report.


It sort of sounds like you have either managed to enter one of the 
Google MX hosts' IP addresses as your domain root A record, or have an 
extra MX record somewhere, or just have the domain root A record pointed 
somewhere outside Google, but without more information it's really hard 
to tell what they're even checking for.


-kgd

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

[Poliman - Serwis]

 Hello. I have used G Suite MX checker available here
https://toolbox.googleapps.com/apps/checkmx/ and I have message: "The
address of the mail server in the domain record A can cause poorly visible
and difficult to diagnose errors manifested by "disappearing" e-mails in
the event of problems with the DNS server. This problem can be diagnosed by
entering a command *telnet your.do.main 25* [..]". How can I resolve this?

In dns zone I have:
ASPMX.L.GOOGLE.COM . with priority 1
ALT1.ASPMX.L.GOOGLE.COM . with priority 5
ALT2.ASPMX.L.GOOGLE.COM . with priority 5
ALT3.ASPMX.L.GOOGLE.COM . with priority 10
ALT4.ASPMX.L.GOOGLE.COM . with priority 10

and I also configured SPF, DKIM, DMARC for my domain.

Does anybody know what to do to resolve this? I know it's not exactly
postfix issue but here are mail related specialists.

-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*

Re: what does it mean?

[Poliman - Serwis]

2018-11-08 14:52 GMT+01:00 Bill Cole <
postfixlists-070...@billmail.scconsult.com>:

> On 8 Nov 2018, at 2:34, Poliman - Serwis wrote:
>
> Honestly I don't fully understand this log. Looks like google mx says that
>> some message from webmas...@kamir-transport.pl belong to ip 54.38.202.128
>> (what is 15 after ip address?) looks suspicious, although is send to
>> another mailbox in this same domain. But both mailboxes are hosted on
>> google, so why google mx mention something about not their ip?
>>
>
> Perhaps because it is an OVH IP and OVH is an open sewer of spam?
>
> It's an unfortunate fact that if your hosting provider has a history of
> accommodating spammers, others will treat you as a spammer by default. OVH
> is such a hosting provider.
>
> PS
>> SPF record configured in DNS zone looks like google advices -> v=spf1
>> include:_spf.google.com ~all
>>
>
> That SPF record probably should be supplemented with any non-Google
> addresses that send messages claiming to be from that domain.
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Available For Hire: https://linkedin.com/in/billcole
>

Maybe you have right but I have no idea how could I check it. Currently I
tested my IP and I am not blacklisted and also clear about sending spam and
my server is not an open relay.
Are you sure that I should supplement this record by some anothers? I
configured it basing on support google ->
https://support.google.com/a/answer/140034?visit_id=636772709321477569-627126811=1
.
-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*