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
