Morning,
I understand the *defer* confusion now ;) Yes, I'm meaning deferring the
message that's already in the exim queue, not being submitted over SMTP.
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.
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.
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 :(
Thanks,
-- Jason
On Thu, Aug 4, 2016 at 4:39 AM, Mike Brudenell <mike.brudenell@???>
wrote:
> Hi, Jason -
>
> On 4 August 2016 at 02:17, Jason <silo82@???> wrote:
>
>> When I said I was hoping exim would defer the message, I meant that the
>> message would remain in the exim queue and be retried during the normal
>> retry intervals. Isn't that what would happen? Your details about the
>> software being able to handle the deferral indicates it wouldn't, and it
>> would be up to the software injecting the message to handle the retries.
>> Why wouldn't exim just keep the message in the queue and retry it on the
>> normal retry schedule if a verification fails/defers?
>>
>
> Sorry, my mind was on *defer* as an ACL verb… There you'd be issuing a
> 4xx SMTP response back to the sending system for the recipient or message,
> and it would be that system's responsibility to try again later if it
> wished.
>
> If you instead *accept* the message in the ACL and merely your router
> defers delivery then yes, the message should continue to live in *your* system's
> queue for retrying later.
>
>
> I had the same suspicions as you about Exim not doing the verify before
>> it sends the message to the smarthost. I did the test using your command
>> with the arguments you mentioned, and I'm just confused now. During
>> startup, the output is normal, and it stops at "Listening...". That seems
>> normal so far. After that, I ran the command to inject a message into the
>> queue ("echo test | mail -s test someone@???"),
>> and nothing showed up in the debug output. Just "Listening..." still.
>> However, checking /var/log/exim4/mainlog I can see the message gets
>> delivered successfully (to the relay at least). That makes no sense. How
>> did exim deliver the message when the debug output never showed a thing?
>>
>
> OK, that "Listening..." is Exim listening for messages arriving over SMTP.
> We merely run SMTP relays to act as a central mail hub for machines on
> campus, so I'm not strong on debugging non-SMTP traffic; I'd hoped you
> might get something logged, but thinking about it now after my morning
> coffee I suspect you wouldn't. Instead I guess "mail" is invoking Exim and
> piping the message into it. So to emulate that you'd need to do something
> similar
>
> As Merlin suggests, is there another option for you: to use SMTP? This
> might give you greater flexibility in terms of any ACLs you need, as we
> talked about earlier. I've never used PHP in my life, but perhaps using
> PHPMailer as suggested by Merlin and in this StackOverflow discussion
> <http://stackoverflow.com/questions/14456673/sending-email-with-php-from-an-smtp-server>
> might be of use?
>
> However I have a sneaky suspicion you'll end up back at Square One: you'd
> be able to verify each recipient using your *verify_address* router,
> accepting the message into your queues for delivery via the smarthost.
> However if there's no DNS entry and you don't want to issue a 4xx SMTP
> response to a recipient but instead accept the message and just hold it,
> unfrozen, in your queues to keep deferring I think you'll have the same
> problem as now.
>
> Is accepting the message but freezing it (the whole message, not just its
> problematic recipients) an option? That way it would be accepted into your
> queues and available for you to check/deal with then unfreeze to retry
> delivery?
>
> 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
>
