sudden issues CentOS 5.10

Wed Feb 27 19:35:49 PST 2019

Receiving servers are simply getting more strict about sender spoofing.

The sending host needs a valid PTR record for it's IP, and sendmail.cf
needs to be written so that it declares itself to be the same fqdn as
whatever that PTR record says.

So for instance I have a digital ocean vm "tandy.wiki", that is the full
fqdn, the tld is .wiki instead of .com etc, and I'm not using any www. for
the hostname.
A few things all have to agree on that name:

* The machine thinks it's own hostname / fqdn is "tandy.wiki"
[root at tandy ~]# uname -n
tandy.wiki
[root at tandy ~]# hostname
tandy.wiki
[root at tandy ~]# hostname --fqdn
tandy.wiki
[root at tandy ~]#

* "tandy.wiki" is a valid domain, and there is an A record named
"tandy.wiki" in the public that points to the IP.

bkw at negre:~$ nslookup tandy.wiki
Server:         10.0.0.1
Address:        10.0.0.1#53

Non-authoritative answer:
Name:   tandy.wiki
Address: 95.85.22.36

bkw at negre:~$

* There is a PTR record in the public dns for that same IP, which points to
the name "tandy.wiki".

bkw at negre:~$ nslookup -type=PTR 95.85.22.36
Server:         10.0.0.1
Address:        10.0.0.1#53

Non-authoritative answer:
36.22.85.95.in-addr.arpa        name = tandy.wiki.

Authoritative answers can be found from:

bkw at negre:~$

* /etc/postfix/main.cf is configured to declare itself to be "tandy.wiki",
which did require reading the comments in the file to understand what it
would try to do by default, to override part of that. Notice in this
excerpt there is only a single uncommented line. $myhostname is filled
automatically with "tandy.wiki" because that is what "hostname" says, and
so I only have to override the described default behavior for mydomain, to
force mydomain to be an exact copy of myhostname, rather than just a
portion of it. So, the end result here is that when postfix sends a mail,
the HELO says "tandy.wiki".

---excerpt of the only part I changed from stock---
# INTERNET HOST AND DOMAIN NAMES
#
# The myhostname parameter specifies the internet hostname of this
# mail system. The default is to use the fully-qualified domain name
# from gethostname(). $myhostname is used as a default value for many
# other configuration parameters.
#
#myhostname = host.domain.tld
#myhostname = virtual.domain.tld

# The mydomain parameter specifies the local internet domain name.
# The default is to use $myhostname minus the first component.
# $mydomain is used as a default value for many other configuration
# parameters.
#
#mydomain = domain.tld
#mydomain = tandy.wiki
mydomain = $myhostname

# SENDING MAIL
#
# The myorigin parameter specifies the domain that locally-posted
# mail appears to come from. The default is to append $myhostname,
# which is fine for small sites.  If you run a domain with multiple
# machines, you should (1) change this to $mydomain and (2) set up
# a domain-wide alias database that aliases each user to
# user at that.users.mailhost.
#
# For the sake of consistency between sender and recipient addresses,
# myorigin also specifies the default domain name that is appended
# to recipient addresses that have no @domain part.
#
#myorigin = $myhostname
#myorigin = $mydomain
---excerpt of the only part I changed from stock---

Now, I can send mail, from sendmail and receiving servers mostly don't
reject it.
gmail etc are satisfied that the IP the mail came from matches the name it
declared itself.

[root at tandy ~]# cat test.eml
To: b.kenyon.w at gmail.com
From: root at tandy.wiki
Subject: This is a test

this is a test email from tandy.wiki

[root at tandy ~]# sendmail -t < test.eml

[root at tandy ~]# tail /var/log/maillog
Feb 28 03:02:19 tandy postfix/sendmail[14775]: input attribute value: 0
Feb 28 03:02:19 tandy postfix/sendmail[14775]: /usr/sbin/postdrop -r -v -v:
wanted attribute: (list terminator)
Feb 28 03:02:19 tandy postfix/sendmail[14775]: input attribute name: reason
Feb 28 03:02:19 tandy postfix/sendmail[14775]: input attribute value: (end)
Feb 28 03:02:19 tandy postfix/sendmail[14775]: /usr/sbin/postdrop -r -v -v:
wanted attribute: (list terminator)
Feb 28 03:02:19 tandy postfix/sendmail[14775]: input attribute name: (end)
Feb 28 03:02:19 tandy postfix/cleanup[14777]: 60EEA41545:
message-id=<20190228030219.60EEA41545 at tandy.wiki>
Feb 28 03:02:19 tandy postfix/qmgr[31133]: 60EEA41545: from=<root at tandy.wiki>,
size=297, nrcpt=1 (queue active)
Feb 28 03:02:19 tandy postfix/smtp[14779]: 60EEA41545: to=<
b.kenyon.w at gmail.com>, relay=gmail-smtp-in.l.google.com[108.177.127.27]:25,
delay=0.34, delays=0.04/0.01/0.11/0.18, dsn=2.0.0, status=sent (250 2.0.0
OK  1551322939 l52si1124580edb.0 - gsmtp)
Feb 28 03:02:19 tandy postfix/qmgr[31133]: 60EEA41545: removed
[root at tandy ~]#

And it is really there in my inbox.

This isn't even touching all the possible issues wih SPF, DMARC, DKIM,... I
don't have any of that set up in dns or in postfix. But I am not trying to
send from this host using any other domain name in the From: address or the
envelop-from. The envelope-from will be local-username at local-hostname, so
"local-hostname" better look good to the receiving server.

As for reptmail, check a few things:
* look inside and search for MTABIN. What is $SENDMAIL?
* do you have a $MYMAIL in your environment? And if so, what is it?
* which "style" option are you using. "T and U just feed into the "mail"
command, most of the others use $SENDMAIL

If you look at the first few lines at the to pf tohtml() you can see what
headers it's going to generate from which variables, and then $SENDMAIL is
the actual sendmail command that it will be piped in to., which you can
check all the way at the bottom.

There is one possible quirk that might come in to effect if you have suid
the mtabin executable, in which case reptmail will detect that and try to
spoof the envelope-from to match MYMAIL. I don't know if that would cause
any problems these days or just be ignored or actually work fine or what.
Could try disabling that part just to remove variables (conceptual
variables I mean that time, not environment variables haha)

On Wed, Feb 27, 2019 at 8:19 PM scooter6--- via Filepro-list <
filepro-list at lists.celestial.com> wrote:

> Have been sending emails forever and a day from this server
>
> They have always shown they're from  root at pdmfl.pdminc.net (which I know
> is
> not really valid but that's another story - was never an issue until
> sometime this afternoon)
>
> After not receiving some automated emails from the server, I look at root
> mail on server and saw these errors:
>
>    ----- The following addresses had permanent fatal errors -----
> <scott.ullmann at pdminc.net>
>     (reason: 553 5.1.8 <root at pdmfl.pdminc.net>... Domain of sender address
> root@
> pdmfl.pdminc.net does not exist)
>
> After changing .muttrc files to make from address  root at pdminc.net
> After changing sendmail.cf to masquerade things etc
>
> I can send command line email via sendmail and mutt
>
> Brian - I can't however make reptmail work?
> Sending reports using reptmail still results in bouncing back to root's
> email with the above error
> I even changed the FROM variable in reptmail to be "root at pdminc.net" but
> still no joy
>
> Any idea what I'm missing here?
>
> I suspect our ISP probably noticed these emails badly formed and maybe
> deleted MX record or something, I don't know....
>
> Only thing that I can't get to work now is reptmail….
>
> Thanks for any insight anyone can give
>
> Scott
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mailman.celestial.com/pipermail/filepro-list/attachments/20190227/4764ceda/attachment.html
> >
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>

-- 
bkw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20190227/3aeafb20/attachment.html>