HOWTO (need) : SSH script, command to change Dmarc TXT setting in DNS of all users/accounts or reseller accont.

[ereemst]

Okay, I have a quick question because of the new changes from Google, Microsoft, etc. and the requirements for the content of the dmarc dns setting!

I am looking for a short SSH command or script that I can run on my Directadmin web servers with Apache and check all accounts on this web server to search and change the existing dmarc setting in the DNS,

for example dmarc=none, or if necessary I want to change the email address stated in all accounts of all my customers.

The reason is that we used a Gmail account for this and this seems to be no longer allowed.

Why we receive this promotion in the Netherlands from a number of well-known providers such as Ziggo or Quicknet and also KPN email bounced from our users who try to send them to these package providers as an example:

*********************
Mail delivery failed: returning message to sender

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:

[email protected]
all hosts for 'quicknet.nl' have been failing for a long time (and retry time not reached)

****************************

Or alternatively a script Grep, whatever to simply remove the TXT record from dmarc's DNS,

Can anybody help me, or He has positive thoughts about this and shares my opinion that this is a problem that needs to be solved

Funny note i tried Bing Pilot asked the question and this came out, Actually does something but does not work (TESTED)

in SSH - ROOT

for user in $(ls /usr/local/directadmin/data/users); do echo "_dmarc=\"v=DMARC1; p=none; sp=none; rua=mailto:spam-reports@$user\"" >> /usr/local/directadmin/data/users/$user/domains/*/dns_txt.conf; done && service named restart

Result
-bash: /usr/local/directadmin/data/users/xxx/domains/*/dns_txt.conf: No such file or directory
-bash: /usr/local/directadmin/data/users/YYY/domains/*/dns_txt.conf: No such file or directory

 

[gate2vn]

You should change in DNS template, and apply to all customers' zones. Have you checked the doc here?

 

[zEitEr]

Hello,

Run to list DNS files where DMARC is added:

grep DMARC $(da c | grep ^nameddir= | cut -d= -f2)/*db

Run to list DNS files where DMARC is NOT added:

for F in $(ls $(da c | grep ^nameddir= | cut -d= -f2)/*db); do grep -q -i DMARC $F || echo $F; done;

as soon as you find a list of domains you can add DMARC records.

I doubt DMARC records with p=none; sp=none; have any sense at all.

 

[Richard G]

I doubt DMARC records with p=none; sp=none; have any sense at all.

Not really indeed, but at least it's sufficient to meet the DMARC requirements of Gmail.

@ereemst if you also want this to be included in newly created domains automatically then copy the:
/usr/local/directadmin/data/templates/dns_txt.conf
to the
/usr/local/directadmin/data/etmplates/custom/
directory. Create this custom directory if it does not exist yet.

Then edit the file there and change what you want, for example add the DMARC line, mine looks like this now:

|DOMAIN|.="v=spf1 a mx ip4:|SERVER_IP||EXTRA_SPF||SPF_IPV6| -all"
_dmarc="v=DMARC1; p=none;"

Be aware, I use -all instead of the default ~all in SPF. If you want to keep that one, only add the second line, so the one from DMARC.

After that, newly created domains will already have the DMARC setting in their DNS.

 

[EthernetServers]

DMARC requirements of Gmail.

Indeed - and Yahoo, they also made the same requirement.

Something like this is probably a good idea, just to gain that bit of extra awareness about activity from one's domain:

v=DMARC1; p=none; rua=mailto:[email protected]

 

[Active8]

my howto that we are using from my notes:

How to automate adding a new DMARC for new domains:

cd /usr/local/directadmin/data/templates/
mkdir custom
cd /usr/local/directadmin/data/templates/custom
cp ../dns_txt.conf .

(mind the dot at the end)
and then add the record you want to the bottom of the custom/dns_txt.conf by running this command:

echo '_dmarc="v=DMARC1; p=reject; sp=none; rua=mailto:spam-reports@|DOMAIN|"' >> dns_txt.conf

 

[Richard G]

by running this command:

I only gave the required very basics to comply with the Gmail and Yahoo requirements.

Be aware that in your example there is a reject policy active. For some it might be better to use none or quarantaine to begin with, to see if they have configured everything correctly like a correct working SPF and DKIM.

@EthernetServers example sends reports but not everyone does want to receive those reports, which is why I only used the basic requirement as example.

Ofcourse one can add things to ones liking, like in both your examples. But I would not set this as default for every domain, most users are not that smart with SPF/DKIM/DMARC

I for example also have a ruf mail address next to the rua and the fo=1;aspf=s at the end. Which can also be set as to one would like to have it.

IMHO best is to have some basic default and the user learns something about it and adjusted it to his/her needs.
Maybe also with a policy, but in that case I would rather use a quarantaine than a reject. Ofcourse, this is everybody's free choice.
Just giving some insights.

 

[zEitEr]

Not really indeed, but at least it's sufficient to meet the DMARC requirements of Gmail.

If to use DMARC, then with either quarantine or reject policy. Default DMARC reports are not user-friendly. So you might use 3rd part solutions to aggregate them.

 

[Richard G]

Default DMARC reports are not user-friendly.

That's in the eye of the beholder imho. I rather use defaults without policy for users than users complaining their forwards don't arrive due to a reject policy or in the spambox, becaused they messed up their SPF or whatever reason.
To me it's more user friendly to have the user choose himself if he does or does not want to use DMARC security insteaf of forcing policy's up to them. As SPF and DKIM is already great anyway.

There are indeed some very nice 3rd party solutions out there for reports, which can also help people to setup their DMARC records as good as possible for them.

 

[zEitEr]

OK, if the feature is created, then users or server administrators would need to use it correct, I believe. Otherwise it's only a way to fool Gmail, Yahoo, MS OutLook.

I understand that hosting users do not have to know how to use SPF, DKIM, DMARC, etc. At the same time I believe they would not like me or anybody else to send emails in behalf of their company's domain. I'm even sure they would dislike it.

If the world is going the way of simplification of things, then users can simply have switches on a web-page:

[X] Allow sending others from my domains
[X] Warm me about attempts to fake emails from my domain
[X] Allow sending from IPs___________________________

Something like that. Otherwise the feature is not used in its power, and it is only about foolling the e-MAIL giants.

 

[Richard G]

Otherwise it's only a way to fool Gmail, Yahoo, MS OutLook.

Correct. However the requirement of Gmail/Yahoo is only for servers sending more than 5K mails/month to them, so for a lot of smaller hosting company's there is not even a need to add the DMARC record.
So at this moment I'm only fooling them indeed with this DMARC record as we don't need it anyway (little company) but just to have it in place, so when a real requirement comes, I can inform all customers and then add a quarantaine policy to it by doing a mass change.

But i've seen too many odd things happening with forwards, especially when a MS account is forwarding at least, not really with Gmail.
When arriving on the MS servers however, then something in the headers is rewritten and the final recepient the mail is forwarded too, will get the mail rejected or in the spamfolder because it then looks as if the mail is send from the MS server, which is not allowed to send mail from our domain.
A lot of our customers use forwards, also via MS mail accounts, which is another reason I rather trust on SPF and DKIM for the moment than now also forcing them a DMARC record with a restrictive policy.

At the same time I believe they would not like me or anybody else to send emails in behalf of their company's domain. I'm even sure they would dislike it.

I fully agree with that. Which is why I've already set a strict SPF record in place with -all and a DKIM record on every domain.
Since some abuse started to raise some time ago, I made the decision on our servers to switch the ~all to -all to put an end to it. That worked great.

Ofcourse if customers do want to use their DMARC, they get the required information and advise from me on how to do things and set it up correctly, pointing to 3rd party's for nicer reports if they want them and so on. I might even set it up for them as a service, no problem.

Best way indeed is as you suggest, that there would be some options for them to choose from and then the according records would be setup correctly for them automatically.
And if all big mail services including MS would play ball according to the RFC's, not rewriting owner headers, so things would work also perfectly on forwarding (as it does on Gmail), then this would gain a lot against abuse of mail.

 

[ereemst]

Oké Thanks for all the good answers and resonses to The QuestionI Asked BUT. the real question was not answered in my belief.Because the real question was, is there away to remove or change from existing users? Dmarc record in the DNS on all existing clients?.
Not New but existing. Or did not read the all you guys there responses to good.. I am Dutch so sometimes my mind wonders of haha.

 

[ereemst]

Correct. However the requirement of Gmail/Yahoo is only for servers sending more than 5K mails/month to them, so for a lot of smaller hosting company's there is not even a need to add the DMARC record.
So at this moment I'm only fooling them indeed with this DMARC record as we don't need it anyway (little company) but just to have it in place, so when a real requirement comes, I can inform all customers and then add a quarantaine policy to it by doing a mass change.

But i've seen too many odd things happening with forwards, especially when a MS account is forwarding at least, not really with Gmail.
When arriving on the MS servers however, then something in the headers is rewritten and the final recepient the mail is forwarded too, will get the mail rejected or in the spamfolder because it then looks as if the mail is send from the MS server, which is not allowed to send mail from our domain.
A lot of our customers use forwards, also via MS mail accounts, which is another reason I rather trust on SPF and DKIM for the moment than now also forcing them a DMARC record with a restrictive policy.


I fully agree with that. Which is why I've already set a strict SPF record in place with -all and a DKIM record on every domain.
Since some abuse started to raise some time ago, I made the decision on our servers to switch the ~all to -all to put an end to it. That worked great.

Ofcourse if customers do want to use their DMARC, they get the required information and advise from me on how to do things and set it up correctly, pointing to 3rd party's for nicer reports if they want them and so on. I might even set it up for them as a service, no problem.

Best way indeed is as you suggest, that there would be some options for them to choose from and then the according records would be setup correctly for them automatically.
And if all big mail services including MS would play ball according to the RFC's, not rewriting owner headers, so things would work also perfectly on forwarding (as it does on Gmail), then this would gain a lot against abuse of mail.

Thx i agree only after 5000 mails, but we (stupid) inserted the Dmarc in all account standard when it came a option in DA, so now how do i UNDO that setting that was so easely put in to remove it from all users at once to comply with GGGGOOOGGGLEE en MMMMSSGATES. etc. Meant to bu funny.

 

[ereemst]

Found read something in the https://docs.directadmin.com/other-hosting-services/dns/maintaining-records.html


Ability to add/delete DNS records from the task.queue
Very raw feature with limited user validation. Use very carefully.

Samples, add/delete:
/usr/local/directadmin/directadmin taskq --run 'action=dns&do=delete&domain=domain.com&type=A&name=mail&value=1.2.3.4'
/usr/local/directadmin/directadmin taskq --run 'action=dns&do=delete&domain=domain.com&type=TXT&name=_acme-challenge&value=*'


Note, that the do=delete does require you pass the "value" as most record types allow duplicate names, thus the value is used to differentiate the records. The ttl can optionally be passed during do=add, but is not required. If dns_ttl=1 is not enabled, the ttl value will have no effect.

For do=delete, if value=* then it will delete all records of that type, with the given name=. So in the example, it will delete all TXT records from domain.com, that have a left-side name of _acme-challenge. This will not catch any full records, like "_acme-challenge.domain.com." as the tool is quite basic.

This method saves needing an API call, and supports all of the clustering pushes.

Note the type must be an upper case character, one of:

• A
• NS
• MX
• CNAME
• PTR
• TXT

so with this info what would be the exact line to use to scan all accounts there DNS records and then use the sample rule to delete the Dmarc txt from all those accounts/ users / payingmybillsguys

 

[Richard G]

Well the DMARC record is a TXT record, so that would be the 2nd example line, except it should read things about DMARC there. Use at own risk!!

But why do you want to remove it? If you don't have a policy added, it won't hurt a bit, so you can just leave it as is and don't need the risk with some commands to remove it again.
Still might come in handy later on maybe.

 

[ereemst]

anybody? give me the command to remove the dmarc from all users on the server of the command to change the email adres in the dmarc setting of all users, not but existing.

 

[Richard G]

You already have the command if all is correct, just change the value.
Make a backup of your /etc/named.conf file and /var/named directory first!!!

Then try this to remove all DMARC records at your own risk!:

/usr/local/directadmin/directadmin taskq --run 'action=dns&do=delete&domain=*&type=TXT&name=_dmarc&value=*'
cd /usr/local/directadmin
echo "action=rewrite&value=named" > data/task.queue; ./dataskq d2000

The last 2 lines take care that the DNS zones will be updated.

If you have a backup, you should in fact be fine.

If you do not want to remove all DMARC records, but only change the rua email address in the records, it might be like this:

cd /var/named/
perl -pi -e 's/[email protected]/[email protected]/' *.db
cd /usr/local/directadmin
echo "action=rewrite&value=named" > data/task.queue; ./dataskq d2000

This will be for all existing records containing the [email protected] mail adres.
The "[email protected]" is current address and "[email protected]" is the new mail adres you want to use. Ofcourse change these mail addresses to your needs.

FYI I'm not 100% sure if these are correct, so be sure you make those backups first!

 

[ereemst]

You already have the command if all is correct, just change the value.
Make a backup of your /etc/named.conf file and /var/named directory first!!!

Then try this to remove all DMARC records at your own risk!:

/usr/local/directadmin/directadmin taskq --run 'action=dns&do=delete&domain=*&type=TXT&name=_dmarc&value=*'
cd /usr/local/directadmin
echo "action=rewrite&value=named" > data/task.queue; ./dataskq d2000

The last 2 lines take care that the DNS zones will be updated.

If you have a backup, you should in fact be fine.

If you do not want to remove all DMARC records, but only change the rua email address in the records, it might be like this:

cd /var/named/
perl -pi -e 's/[email protected]/[email protected]/' *.db
cd /usr/local/directadmin
echo "action=rewrite&value=named" > data/task.queue; ./dataskq d2000

This will be for all existing records containing the [email protected] mail adres.
The "[email protected]" is current address and "[email protected]" is the new mail adres you want to use. Ofcourse change these mail addresses to your needs.

FYI I'm not 100% sure if these are correct, so be sure you make those backups first!

TOP ga ik testen.

 

[Richard G]

TOP ga ik testen.

Succes. Laat even weten of het gelukt is!