Prev: sane filesystem quotas with maildir
Next: sendmail.postfix not starting due to time mismatch
From: Carlos Williams on 18 Dec 2009 15:25
I notice from time to time by checking my mail queue that messages get
stuck there because users send to an invalid or non existing domain.
My Postfix server attempts to hold the message in queue for later
delivery assuming the remote server could be experiencing issues right
his moment. My question is can I simply run a command to force a
delivery failure rather than issuing the 'postsuper -d queue_id'? If I
run the 'postsuper' command, the message is simply deleted from the
queue and vanishes never to be heard from again. I want to force
Postfix to return the message with a delivery failure to the sender.
Is this possible?

I searched man postsuper & Google and could not find anything I was looking for.

Thanks!

From: Aaron Wolfe on 18 Dec 2009 17:01
On Fri, Dec 18, 2009 at 3:25 PM, Carlos Williams <carloswill(a)gmail.com> wrote:
> I notice from time to time by checking my mail queue that messages get
> stuck there because users send to an invalid or non existing domain.
> My Postfix server attempts to hold the message in queue for later
> delivery assuming the remote server could be experiencing issues right
> his moment. My question is can I simply run a command to force a

I think you might be trying to solve the wrong problem. Why queue
mail for destinations that don't have MX records (typoed domain part,
etc)? Better to return undeliverable to senders I would think. This
is different than mail to domains that exist and do have MX records,
but postfix cannot reach the MX for some reason.

Did you change smtp_defer_if_no_mx_address_found from its default
setting of 'no'? Maybe there is a reason to do this, but I don't see
it. It will cause the problem you are describing.


> delivery failure rather than issuing the 'postsuper -d queue_id'? If I
> run the 'postsuper' command, the message is simply deleted from the
> queue and vanishes never to be heard from again. I want to force
> Postfix to return the message with a delivery failure to the sender.
> Is this possible?
>
> I searched man postsuper & Google and could not find anything I was looking for.
>
> Thanks!
>

From: Carlos Williams on 18 Dec 2009 17:15
On Fri, Dec 18, 2009 at 5:01 PM, Aaron Wolfe <aawolfe(a)gmail.com> wrote:
> I think you might be trying to solve the wrong problem.  Why queue
> mail for destinations that don't have MX records (typoed domain part,
> etc)?  Better to return undeliverable to senders I would think.  This
> is different than mail to domains that exist and do have MX records,
> but postfix cannot reach the MX for some reason.

OK.

> Did you change smtp_defer_if_no_mx_address_found from its default
> setting of 'no'?  Maybe there is a reason to do this, but I don't see
> it.  It will cause the problem you are describing.

No I did not 'change it from the default parameter according to Postfix.

[root(a)mail ~]# postconf -d | grep "smtp_defer_if_no_mx_address_found"
smtp_defer_if_no_mx_address_found = no

Are you suggestion I leave my server as is or I change the mentioned
above parameter to "yes"? What you say makes sense...why queue
messages and Postfix / system resources trying to redeliver messages
for domains that don't have valid MX records. This seems wasteful so
should I simply not just change the parameter to yes or will that have
some consequences that could bite me later like if a domain I send
mail to heavily has a MX record problem for an hour. Rather than
sending all those messages, it will just refuse to send to them.

From: Noel Jones on 18 Dec 2009 17:41
On 12/18/2009 4:15 PM, Carlos Williams wrote:
> On Fri, Dec 18, 2009 at 5:01 PM, Aaron Wolfe<aawolfe(a)gmail.com> wrote:
>> I think you might be trying to solve the wrong problem. Why queue
>> mail for destinations that don't have MX records (typoed domain part,
>> etc)? Better to return undeliverable to senders I would think. This
>> is different than mail to domains that exist and do have MX records,
>> but postfix cannot reach the MX for some reason.
>
> OK.
>
>> Did you change smtp_defer_if_no_mx_address_found from its default
>> setting of 'no'? Maybe there is a reason to do this, but I don't see
>> it. It will cause the problem you are describing.
>
> No I did not 'change it from the default parameter according to Postfix.
>
> [root(a)mail ~]# postconf -d | grep "smtp_defer_if_no_mx_address_found"
> smtp_defer_if_no_mx_address_found = no

"postconf -d" shows built-in defaults, not the settings
currently used. For current settings, use "postconf".

At any rate, that parameter likely has no effect on your problem.

Many common typo domains have valid A or MX records, but the
target hosts don't answer on port 25. Another common cause is
domains that constantly return "fail" rather than "don't exist".

These are temporary errors that postfix rightfully keeps in
the queue. A computer can't tell the difference between a
temporary error that is likely to continue forever and a
"real" temporary error.

[didn't I just answer this question from another poster a few
minutes ago??]

Your choices are to just ignore it and let the mail be
returned when $max_queue_lifetime is reached, or you can help
postfix out by adding a transport_maps entry for the offending
domain. Something like:
# main.cf
transport_maps = hash:/etc/postfix/transport

# transport
# these are some I commonly see; yours may be different
hotmial.com error:5.1.2 hotmail.com not hotmial.com
hotmai.com error:5.1.2 hotmail.com not hotmai.com
aoil.com error:5.1.2 try "aol.com" instead
gmial.com error:5.1.2 try "gmail.com" instead
comcaste.net error:5.1.2 try "comcast.net" instead
comcat.net error:5.1.2 try "comcast.net" instead
comcost.com error:5.1.2 try "comcast.net" instead
comcst.net error:5.1.2 try "comcast.net" instead
c0mcast.net error:5.1.2 try "comcast.net" instead
cherter.net error:5.1.2 try "charter.net" instead



To answer your earlier question about how to force failure of
a single message in the queue, postfix has no built-in
function for that. The best work-around is to (temporarily)
add a header_checks rule to reject the Message-ID: of that
message, then requeue the message with "postsuper -r QUEUEID".


-- Noel Jones

From: Carlos Williams on 18 Dec 2009 18:03
On Fri, Dec 18, 2009 at 5:41 PM, Noel Jones <njones(a)megan.vbhcs.org> wrote:
> "postconf -d" shows built-in defaults, not the settings currently used.  For
> current settings, use "postconf".

Woops.

> These are temporary errors that postfix rightfully keeps in the queue.  A
> computer can't tell the difference between a temporary error that is likely
> to continue forever and a "real" temporary error.
>
> [didn't I just answer this question from another poster a few minutes ago??]

I don't remember asking this before but I am usually wrong.

> Your choices are to just ignore it and let the mail be returned when
> $max_queue_lifetime is reached, or you can help postfix out by adding a
> transport_maps entry for the offending domain.  Something like:
> # main.cf
> transport_maps = hash:/etc/postfix/transport
>
> # transport
> # these are some I commonly see; yours may be different
> hotmial.com   error:5.1.2 hotmail.com not hotmial.com
> hotmai.com    error:5.1.2 hotmail.com not hotmai.com
> aoil.com      error:5.1.2 try "aol.com" instead
> gmial.com     error:5.1.2 try "gmail.com" instead
> comcaste.net    error:5.1.2 try "comcast.net" instead
> comcat.net   error:5.1.2 try  "comcast.net" instead
> comcost.com   error:5.1.2 try  "comcast.net" instead
> comcst.net   error:5.1.2 try  "comcast.net" instead
> c0mcast.net     error:5.1.2 try "comcast.net" instead
> cherter.net     error:5.1.2 try "charter.net" instead

Very helpful!

 | 
Pages: 1
Prev: sane filesystem quotas with maildir
Next: sendmail.postfix not starting due to time mismatch