why does some outgoing mail constantly end up "Deferred" ?
wfdudley at gmail.com
Fri Apr 14 21:38:25 UTC 2017
Thanks, that was very helpful.
My problem was a broken STARTTLS implementation -- so the connection
would fail when that failed, and the mail got deferred.
For now, I've turned off STARTTLS stuff entirely.
This email is free of malware because I run Linux.
On Fri, Apr 14, 2017 at 2:53 PM, Jon Radel <jon at radel.com> wrote:
> On 4/14/17 1:37 PM, William Dudley wrote:
> > This, in /var/log/maillog:
> > Apr 14 13:17:52 dudley sm-mta: v3ALsCcO098060: to=<
> > lemontree66 at sbcglobal.net>, delay=3+19:23:38, xdelay=00:00:00,
> > mailer=esmtp, pri=16918651, relay=al-ip4-mx-vip1.prodigy.net.,
> > stat=Deferred
> > Apr 14 13:17:52 dudley sm-mta: v3ALsCci098060: to=<
> > markj at limerockcontractors.com>, delay=3+19:23:34, xdelay=00:00:00,
> > mailer=esmtp, pri=16918660, relay=limerockcontractor...ction.outlook.com
> > dsn=4.0.0, stat=Deferred
> > These mails sit in my queue, get retried, and are constantly "Deferred".
> If they were in the queue for only a short period and then were
> eventually sent, I'd suspect gr[a|e]ylisting. If it were some obscure
> little domain where the MX host had connectivity problems, well, that
> would be it.
> But 3+ days delay, where most of the mail is going to some Microsoft
> service offering.... It's probably something else. Unless you and/or
> your ISP have broken TCP port 25 connectivity entirely....but you say
> that this happens only with some mail.
> The very first thing I'd do, as root, is to run
> sendmail -qf -v
> which will ask sendmail to run through the queues once, in the
> foreground, and report in verbose mode what it thinks is happening as it
> tries to send each piece of mail waiting in the queues, and probably
> most usefully, what text the other side SMTP server sends to explain
> what it is doing. Assuming that it doesn't just time out trying to reach
> the remote server, which would also be obvious. Most sensible servers
> send at least some hints for the humans along with the response code.
> After that I'd confirm that forward DNS, reverse DNS, and how your SMTP
> server identifies itself (should be obvious in the verbose output),
> match up sensibly, and your DNS data is accessible to the Internet at
> large. Getting that wrong makes you look way too much like some random
> drive-by spammer.
> --Jon Radel
> jon at radel.com
More information about the freebsd-questions