this is the message a few emails our mailserver sends gets.
this is our setup.
We have 2 sending and recieving mailservers one in each office and 1 email sending concentrator server.
The concentrator gets emails from several internal webservers and then sends messages out from that server.
In DNS we only have 2 mx records one for each mailserver that recieves none for the sending server and our ISP has a reverse lookup for the sending concentrator smtp server.
Now before we had the concentrator sending emails using one of our mx record servers as a relay. for performance and other reasons we stop this and sent the emails directly. But a small handful of mail servers out there rejects our emails based on the error message above.
What did i miss in our configuration that needs to be configured to have this work. Because the other 2 mail servers have no issues with batv but they also have proper mx recrods. We dont want mx records for the concnetrator because it never , ever recieves email.
also the concentrator is behind a firewall and it only has port 25 open to it.
all 3 systems are astaro. I called astaro but they said there system requires no special configuration for this so i am thinking its something wrong with the overall design of our mailsystem.
this was the first reply i got on a help forum.
One suggestion (see below) is to strip out the Return Address header from your emails that have this problem. It is possible to do this using the Content Filter in Mdaemon.
Bounce Address Tag Validation - Wikipedia, the free encyclopedia
This was my reply
i dont understand ?
we have a few hundred of emails out of hundreds of thousands of emails that get this bounce back. How can i do this per message.
also do you find any problems in our setup ?
ive read that BATV wiki before and i guess it goes over my head but i dont understand it.
according to this, emails are sent out with a key, if a return email comes in ( from a spammer) that doesnt hae this key its rejected.
But the issue i have is that we send an email to a remote email server for that mail server to deliver to the user. We are not bouncing back a message. So the message is from a legit smtp server. So why is this remote server saying that the batv is not valid, should the remote server even be doing a batv check unless the message we are sending is a bounce back.
this was there reply to my reply.
The reason I suggest you use Mdaemon's Content Filtering (CF) is that, every time you receive a BATV related bounce you include a Rule in CF which says "for this recipient strip out Return Address" or do whatever is necessary to get the message accepted - you may have to try a few things because this is a workaround you are trying to concoct - but it is easy and quick to test. Doing it this way using CF ensures that the bulk of your messages are unmodified.
The problem that some recipient mail servers appears to have, according to the reference cited, is that they have a bug when handling certain messages. You have two options, either you inform the recipient of the problem ...and you know they're going to say that they get x emails a day, this has nothing to do with our side, yada yada yada, or you take the initiative and deal with it - kludge it to work from your end.
The essence of the solution as I read it is that BATV doesn't bounce messages that don't have Return Addresses set to prevent a Mail Loop. So configure your message as if it were a Bounce message (rather than an original message) and check with a "test, please reply" message to see that such a bounce is not discarded by the recipient mail server.
Mdaemon supports BATV, but this is on messages you send that might come back. What you have here is a recipient who has implemented BATV at their end, which is the converse.
N.B. This is my interpretation. I am open to being corrected on this.
I dont understand how to do this with astaro.
This thread was automatically locked due to age.
