Local Email Delivery

Discussion in 'ISPConfig 3 Priority Support' started by BobGeorge, Oct 21, 2018.

  1. BobGeorge

    BobGeorge Member HowtoForge Supporter

    I've got a website with a contact form, which delivers to a local ISPConfig mailbox, via another local ISPConfig mailbox (which may or may not, in fact, sometimes be the same local mailbox, sending to itself) using SMTP.

    These emails are getting stuck - it keeps retrying delivery until it gives up.

    But if I manually - using an email client, like Thunderbird - send an email from the sending mailbox to the receiving mailbox, this sends just fine. So email delivery, via SMTP, between these mailboxes does work, it just isn't working when a website attempts to do the same thing.

    I'm trying to work out what's different to cause one to get stuck but the other to send just fine. Is this perhaps a SpamAssassin thing?

    I do want to allow clients to be able to send emails via their mailbox, if they have one, from their website - as mentioned, websites often have contact forms and if they've got a website and an email with us, then they should be able to direct that contact form to our provided mailbox. Indeed, this is, for many clients, pretty much the entire reason why they've got an email with us.

    The web server (Apache + PHP-FPM) and email server (postfix) are on the same machine here. So this is an SMTP to 127.0.0.1 - and I've tried a "telnet 127.0.0.1 587" on that machine and the email server responds, as expected.

    The email is getting into the system - I can see it being queued in mail.log (and I did write some PHP code, using PHPMailer, to send an email and turned on debugging output, and the SMTP session goes entirely smoothly with a "message queued" at the end) and, of course, the fact that it repeatedly tries delivery and then gives up itself tells us that the SMTP is working.

    It's just that the email gets stuck. It doesn't actually get delivered and eventually I get an "Undelivered mail returned to sender" when it gives up.

    Yet if I send an email from the sending email to the receiving email - in the usual way, with an email client - then these emails get through without issue. So the exact same thing - other than that the point of origin is not 127.0.0.1 when I send through Thunderbird - but one works, while the other gets stuck.

    It is, indeed, ironically backwards. External email sails through just fine, but it's the internal emails - on 127.0.0.1 - that get stuck and never arrive, which you'd think should be easier, as it's just sending to itself.

    I'm wondering if it's a SpamAssassin thing, or a Postfix configuration thing. Some setting I need to tweak.
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    Which messages do you get in the mail.log on both servers when delivery fails?
     
  3. BobGeorge

    BobGeorge Member HowtoForge Supporter

    Okay, pardon the long delay, but the boss deemed other things to have priority, so I'm only just getting back to this now.

    In "mail.log", the submission/smtpd stuff looks fine, but then it's followed by this:

    Nov 15 10:44:54 node0 postfix/smtpd[15522]: fatal: unexpected command-line argument: 10.0.0.0/8
    Nov 15 10:44:55 node0 postfix/master[32431]: warning: process /usr/lib/postfix/sbin/smtpd pid 15522 exit status 1
    Nov 15 10:44:55 node0 postfix/master[32431]: warning: /usr/lib/postfix/sbin/smtpd: bad command startup -- throttling

    So the startup of SMTPD is going wrong there, as it's not recognising the argument "10.0.0.0/8". This would be my internal network. But I don't why that's there. Where could it be picking up this IP range from and why is this a problem exactly? As it doesn't provide the actual erroneous command line in full, I can only guess...
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    Find out where you added that in the postfix config, either in main or master cf file, and then post that line if you don't know how to correct it or correct it right away as there is probably a typo or something is missing in that line.
     
  5. BobGeorge

    BobGeorge Member HowtoForge Supporter

    In "main.cf", we have:

    mynetworks = 127.0.0.0/8 [::1]/128 10.0.0.0/8

    In "master.cf", we have:

    -----
    amavis unix - - y - 2 smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes
    -o smtp_bind_address=
    127.0.0.1:10025 inet n - n - - smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8 10.0.0.0/8
    -o strict_rfc821_envelopes=yes
    -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
    -o smtp_send_xforward_command=yes
    -o disable_dns_lookups=yes


    127.0.0.1:10027 inet n - n - - smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8 10.0.0.0/8
    -o strict_rfc821_envelopes=yes
    -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
    -o smtp_send_xforward_command=yes
    -o milter_default_action=accept
    -o milter_macro_daemon_name=ORIGINATING
    -o disable_dns_lookups=yes

    -----

    (I didn't add that to "master.cf" myself, but I noticed the "10.0.0.0/8" in there and, thinking about how command lines usually work, that space between the IP ranges would be interpreted as separate arguments, yes? I notice that none of the others have spaces and use commas instead, which would make sense with how command line arguments are space-delimited. So that strikes me as wrong, but I didn't edit that myself. Indeed, I've not touched "master.cf" other than the changes you need to make in the "perfect server" I followed. Perhaps it picked that up from another config file, where it's been specified incorrectly?

    I could manually fix that, but I don't want it to just automatically restore the error again later. But this does suggest to me that it's the amavis config that's not quite right. I'll go look.)
     
  6. BobGeorge

    BobGeorge Member HowtoForge Supporter

    I did do the manual fix - just to test if that was the problem - and the emails are coming through, so it appears that it was the issue.

    But, hmm, how did it go wrong in the first place?
     
  7. till

    till Super Moderator Staff Member ISPConfig Developer

    I don't think that ISPConfig added the 10.... range, so it must have been added manually on your system.
     

Share This Page