Missing EOL in main.cf

  • As there've been problems with spamming webspaces in the past, I somewhen decided to deny relaying mails through postfix without smtp-auth. However, in order to avoid patching imscp at every release, I defined a few exceptions. This is possible by setting "authorized_submit_users = root, vu2000, vmail" in main.cf


    Nuxwin: So why I'm writing this? :-) I just applied the postfix-listener by using "afterMtaBuildAliasesDb" (as you proposed a few days ago) and, in parallel with the Spamassassin-Plugin, I get



    authorized_submit_users = root, vu2000, vmailmilter_connect_macros = j {daemon_name} v



    in the final config. So is the missing \n due to the workaround with the modified event or is the plugin the initial problem? Just did a change to the plugin-configuration and updated the plugin just right before.



    (Yes, I know you commited a change in the event-handling but I didn't do a checkout from the trunk so far)



    Thanks in advance.

  • @biologist


    How did you added the authorized_submit_users parameter? The problem seem to be on your side ;) We are using POSTCONF(1) to modify the main.cf. Thus, if there is a missing EOL, that surely because at time you added the authorized_submit_users parameter, you forgot to add that EOL (surely at end of file).


    Please:

    • Show us the content of your postfix tuning listener (you should add the authorized_submit_users parameter in that file)
    • Show us the content of your main.cf before any i-MSCP processing if you edited it manually
    • Give us the version of your SpamAssassin plugin.

    Thread moved to development section.


    BTW: Your idea about denying relay for unauthenticated user is really good and we should have this enabled by default. Doing this would prevent users (or any hacked script) to send mail Through PHP mail() function which use sendmail binary. This would force customer to use PHP smtp client and authenticate with SASL.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • Well, the point is that I included the directive somewhere in the middle of the block - not at the end. Looks like this


    [...]
    'smtp_tls_loglevel' => '1',
    'authorized_submit_users' => 'root, vu2000, vmail',
    'tls_high_cipherlist' => 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL::!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA::DES-CBC3-SHA:DES-CBC3-SHA',
    [...]


    Now I've been recreating the configuration using imscp-reconfigure (not just updating the plugin) and it's fine. So I don't know where I could possible add a newline!? :-) Plugin-version is 1.1.1.


    Regarding smtp-auth: I always had to kick the client's ass in order to get them updating their webspaces. But in the end, they didn't/don't do. However, was a good decision to refuse mailrelaying without smtp-auth. But the downside is when you have dozens of clients - usually their webcontents rely on relaying mail without using smtp-auth. It's a hard way to explain to every client that smtp-auth is necessary in future. Even for wordpress for example you need a plugin.
    Additionaly, only postfix-user is allowed (restricted by iptables/iptables6) to send mails to dport 25/465/587. And this is by far more important, because you usually don't take notice when a webspace is spamming without using your mta.
    For sure, only ports necessary are allowed in my firewall. And I can tell you: there were dozens of times where an suspious process was started in the client's context which tried to reach a command-and-qonquer-server. But that's another story... :-)

  • So I don't know where I could possible add a newline!? Plugin-version is 1.1.1.

    My thinking was that you were added the authorized_submit_users parameter manually. What why I said "You forgot to add EOL..."


    Now I've been recreating the configuration using imscp-reconfigure (not just updating the plugin) and it's fine. So I don't know where I could possible add a newline!? Plugin-version is 1.1.1.

    And there is no longer missing EOL? How did you processed the first time? I would want track the issue but I need the exact steps to reproduce ;)

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • Hmm, maybe you're right. In the beginning I've been editing main.cf manually - just in order to test it. After that I added the line to the listener. Possibly I forgot to remove the manual entry in main.cf and updated the plugin subsequently which could have led to the behaviour I described above.


    So yes, possibly it was just my fault - sorry :-)
    I'll keep an eye on it and tell you if the problem occures again (without my manual interaction) :-)


    Thank you!