Afternoon, :-)
On 4 August 2016 at 15:47, Jason <silo82@???> wrote:
> I would have expected exim to log *everything* it's doing if it's in debug
> mode. Be it SMTP, or queue processing/delivery. Weird that is isn't.
>
Nope, not weird… The command I gave you started Exim in daemon mode (that's
the *-bd*) to listen for incoming SMTP connections. Because you're not
talking SMTP to it that software instance doesn't get to to do anything,
hence no debug output.
Instead you're using something else to invoke a *separate* instance of
Exim: most likely involving PHPMailer invoking the de fact standard "mail"
program, which will in turn most likely invoke the de facto standard
/usr/lib/sendmail and pipe your message into it for delivery. (Both mail
and sendmail have been around since the Year Dot.) However if your system
is like mine then /usr/lib/sendmail is a symlink to /usr/sbin/exim4 and
mail actually invokes *that* way. So if you manage to start *that* exim
with a *-d+all* command line option you should get debugging, although it
would come out for whatever is running the mail command.
The test you tried before was
echo test | mail -s test someone@???
so the equivalent using Exim (with the debugging option) directly is
something like
echo test | /usr/sbin/exim -d+all -i someone@???
Note that depending on your Exim setup you might need to run that as root;
we have various permissions set so that mere mortal users can't use the
above, but could via the standard mail utility.
> I checked the code real quick, and they (the devs) are using PHPMailer
> to send the mail. However, they're not using the SMTP functionality of
> PHPMailer to do it. The default, I guess, is for PHPMailer to just inject
> the message into the localhost queue (which they're doing). They could
> likely change it to use SMTP and deliver to localhost, but I don't think
> they'll want to. Simply because doing that would introduce more
> overhead/time to send a message, I'd think. i.e., sending a message by
> making an SMTP connection would take more time than just injecting the
> message directly. It's probably an insignificant amount of time
> difference, but when they run a mailing list batch of email they want it to
> return as quickly as possible.
>
You might have to strike a balance with the devs… I'd like a car the size
of a mini but with the build quality and fitments of a Rolls Royce, but I
can't have it; somewhere there has to be a compromise. :-)
By using non-SMTP submission they're constraining you to non-SMTP ACLs,
which give you no ability to accept, defer or reject individual recipients;
instead you can only accept or reject the entire message. If you were using
SMTP-based submission and the SMTP ACLs then you could verify each
recipient individually and issue an SMTP-based defer; but it would then be
up to the sending software to do something sensible with/retry those
deferred recipients (which your devs probably wouldn't like either! :-)
> Accepting the message but freezing it really isn't going to work,
> either. We don't want to have to deal with unfreezing messages on a
> regular basis. Ideally, we'd have the messages injected into the queue and
> deferred until dnslookup returns OK (or the message was in the queue for 7
> days and fails delivery). But I'm thinking we're not going to be able to
> get exim to do that :(
>
It's an interesting problem, with a very valid use-case: hold messages in
your queue until you can see they have valid DNS entries and you'd be able
to deliver them yourself but then transmit them to Amazon SES for delivery…
I'm still pretty sure there must surely be a way to get Exim to do handle
this in one go.
But in the meantime one solution I think might work would be to fire up a
separate server/smarthost with Exim running in daemon mode:
1. Your devs' PHP code dumps their messages into their PHP server's
queues using non-SMTP.
2. Exim on that PHP server is configured to send to your new smarthost
over SMTP.
3. On your new smarthost you use *verify = recipient* as we've discussed
previously and *defer* (recipients) that don't have valid DNS entries;
they get queued up in the PHP server's Exim, whilst the 'good' recipients
your smarthost accepts are transmitted onward to Amazon SES.
4. Exim on the PHP server will keep retrying periodically to send
messages with the dodgy recipients to your new smarthost. If they become
good then they'll go through; otherwise they'll eventually time out.
It's a bit of a kludge, but I think it would work at the cost of setting up
another Exim server and introducing an SMTP hop. (Shh! Don't tell the devs!
:-)
Does anyone else have an idea how Jason can achieve this "pre-vetting" that
addresses he's accepted into his queues have recipients with valid DNS
entries before routing onward to an Amazon SES smarthost?
Cheers,
Mike B-)
--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Web:
www.york.ac.uk/it-services
Disclaimer:
www.york.ac.uk/docs/disclaimer/email.htm
