Local Email Delivery

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.

 

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...

 

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.)

 

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?