Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


[Tutorial] Changing outgoing SMTP email on Postfix MTA.
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

[Tutorial] Changing outgoing SMTP email on Postfix MTA.

rogriveracrogriverac Member
edited March 2013 in Tutorials

We, at VelociHOST would like to start building a comprehensive tutorial section on our knowledgebase to help the community on giving what we all needed at the beginning of our journey. But we want it to be from day to day problems, including our own experiences. Today we’re starting with How to Change Outgoing SMTP email on Postfix MTA. This has made our way to avoid spam filters with our outgoing mails. Please feel free to check today’s post here

Comments

  • Congratulations. But please stop spamming us, spam your clients instead.

  • This is a tutorial category. We really think giving up helpful information to other is not spam. We're sorry for your point of view.

  • natestammnatestamm Member
    edited March 2013

    @rogriverac I think what you're doing is virtuous. And having quite a bit of experience with this may be I can offer some pointers to help your guide. The biggest of which would simply be that the hostname of the mail server *could match the hostname of one "authoritative" domain. Now in a lot of PCI compliance situations your hostname for the server may not match the SMTP banner and mailname *and your testing company will let you know, which makes your solution a great way for some one to keep any hostname for the server they want while still having mail from a local user broadcast using the appropriate domain name and not have these "names" restricted to some actual domain . Lots of people just set the whole box to mail.domain.com which is the poor mans way of blowing through compliance tests, I do it myself on plenty of machines


    But even in this I would interject that using local users for your mail accounts is not the best thing to do. Virtual accounts and domains are a preferred way to manage the Email activities when one might have several different domains hosted on a box.

    So it really depends if this is a company or network based solution in which case you really don't need to do What your tutorial is stating, can easily get away setting hostnames, mailnames, and SMTP banners all to the same mail domain. But if you are hosting various separate clients and business entities they will most likely want to be connecting SMTP to domains that match those they have registered et al And I would agree you have a good solution there for Postfix. *And of course compliance tests won't be directed at your hosted clients so it works out.

    Some other points I would refine a little bit. I wouldn't call the user account the Email ID. That could confuse some folks who have DKIDS in mind, not to mention a person who might be new to the server setup and config scene could misinterpret that to mean actual user and group account IDs for the box. Also, When I started to read your tutorial I was at first thinking you were referring more to SMTP authentication, a very important metric that ends up in lots of mail being rejected by some major providers out there, Comcast was one that I always *used to see rejecting mail that was not authenticating SMTP. Your tutorial while still very important, That is having an aproriate domain following the account name <- just had me wondering if you were trying to relate the two, which they really are not 100% related. In fact reading it over a few times I think you're already past the point of the local user authenticating SMTP.


    Any ways Sorry for the long response But I live and breathe mail servers, Feedback loops, and mail marketing programs. I think we do need more explanations for people trying to set this up And your tutorial is providing help in that regard. Good stuff +1

  • @natestamm I really appreciate your valuable extension to our tutorial. We definitely agreed that our solution is suited for the classic multiple domain scenario we see on many users with one single VPS/Box. This time we just wanted to keep the Postfix workaround simple to accomplish in this type of situations.

    I deeply believe there are even other elements that you mentioned that are of more value to the mail server verification like Domain Keys Identified Email and I would even add the Sender Policy Framework to complete the authentication most mail servers require to avoid throwing clients mails to the spam folder.

    With all this, I will be presenting a more comprehensive tutorial with your valuable contribution for those in need of this kind of spam fighting solutions. Than you very much.

Sign In or Register to comment.