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 <[email protected]> wrote: > Hi, Jason - > > On 4 August 2016 at 02:17, Jason <[email protected]> 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 [email protected]"), >> 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 > -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
