Bounce mails manually

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Bounce mails manually

Emanuel
Hello,

It's possible bouncing email manually with the ID in the queue?

In the documentatión from de the command postqueue or postsuper i not
find any information.

Regards,

--
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

Wietse Venema
Emanuel:
> Hello,
>
> It's possible bouncing email manually with the ID in the queue?
>
> In the documentati?n from de the command postqueue or postsuper i not
> find any information.

That's because bounce by ID is not supported.

You can bounce all mail for a specific recipient or a specific domain
with a transport map.

/etc/postfix/main.cf
    transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport
    example.com                 error:text why mail is bounced
    [hidden email]      error:text why mail is bounced

Instead of hash: you can use any Postfix darabase type.

This also prevents the Postfix SMTP server from accepting new email
for that recipient or domain.

A postsuper 'bounce' option would require
- Must be invoked by root.
- Drop privileges down to the postfix user.
- Lock the queue file for exclusive access.
- Either set a new flag in the queue file that the message must be bounced,
- Or for each recipient in the queue file send 'why mail is bounced'
  to the bounce daemon.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

azurIt

Citát Wietse Venema <[hidden email]>:

> Emanuel:
>> Hello,
>>
>> It's possible bouncing email manually with the ID in the queue?
>>
>> In the documentati?n from de the command postqueue or postsuper i not
>> find any information.
>
> That's because bounce by ID is not supported.
>
> You can bounce all mail for a specific recipient or a specific domain
> with a transport map.
>
> /etc/postfix/main.cf
>     transport_maps = hash:/etc/postfix/transport
>
> /etc/postfix/transport
>     example.com                 error:text why mail is bounced
>     [hidden email]      error:text why mail is bounced
>
> Instead of hash: you can use any Postfix darabase type.
>
> This also prevents the Postfix SMTP server from accepting new email
> for that recipient or domain.
>
> A postsuper 'bounce' option would require
> - Must be invoked by root.
> - Drop privileges down to the postfix user.
> - Lock the queue file for exclusive access.
> - Either set a new flag in the queue file that the message must be bounced,
> - Or for each recipient in the queue file send 'why mail is bounced'
>   to the bounce daemon.
>
> Wietse



But it would be REALLY usefull feature, i was searching for such thing  
some time ago too.

azur


Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

Wietse Venema
[hidden email]:

>
> Cit?t Wietse Venema <[hidden email]>:
>
> > Emanuel:
> >> Hello,
> >>
> >> It's possible bouncing email manually with the ID in the queue?
> >>
> >> In the documentati?n from de the command postqueue or postsuper i not
> >> find any information.
> >
> > That's because bounce by ID is not supported.
> >
> > You can bounce all mail for a specific recipient or a specific domain
> > with a transport map.
> >
> > /etc/postfix/main.cf
> >     transport_maps = hash:/etc/postfix/transport
> >
> > /etc/postfix/transport
> >     example.com                 error:text why mail is bounced
> >     [hidden email]      error:text why mail is bounced
> >
> > Instead of hash: you can use any Postfix darabase type.
> >
> > This also prevents the Postfix SMTP server from accepting new email
> > for that recipient or domain.
> >
> > A postsuper 'bounce' option would require
> > - Must be invoked by root.
> > - Drop privileges down to the postfix user.
> > - Lock the queue file for exclusive access.
> > - Either set a new flag in the queue file that the message must be bounced,
> > - Or for each recipient in the queue file send 'why mail is bounced'
> >   to the bounce daemon.
> >
> > Wietse
>
>
>
> But it would be REALLY usefull feature, i was searching for such thing  
> some time ago too.

Why? Someone was drunk and sent a bad email? Is "postsuper -d" not
sufficient?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

azurIt

Citát Wietse Venema <[hidden email]>:

> [hidden email]:
>>
>> Cit?t Wietse Venema <[hidden email]>:
>>
>> > Emanuel:
>> >> Hello,
>> >>
>> >> It's possible bouncing email manually with the ID in the queue?
>> >>
>> >> In the documentati?n from de the command postqueue or postsuper i not
>> >> find any information.
>> >
>> > That's because bounce by ID is not supported.
>> >
>> > You can bounce all mail for a specific recipient or a specific domain
>> > with a transport map.
>> >
>> > /etc/postfix/main.cf
>> >     transport_maps = hash:/etc/postfix/transport
>> >
>> > /etc/postfix/transport
>> >     example.com                 error:text why mail is bounced
>> >     [hidden email]      error:text why mail is bounced
>> >
>> > Instead of hash: you can use any Postfix darabase type.
>> >
>> > This also prevents the Postfix SMTP server from accepting new email
>> > for that recipient or domain.
>> >
>> > A postsuper 'bounce' option would require
>> > - Must be invoked by root.
>> > - Drop privileges down to the postfix user.
>> > - Lock the queue file for exclusive access.
>> > - Either set a new flag in the queue file that the message must  
>> be bounced,
>> > - Or for each recipient in the queue file send 'why mail is bounced'
>> >   to the bounce daemon.
>> >
>> > Wietse
>>
>>
>>
>> But it would be REALLY usefull feature, i was searching for such thing
>> some time ago too.
>
> Why? Someone was drunk and sent a bad email? Is "postsuper -d" not
> sufficient?
>
> Wietse




Use case: Users are sending undeliverable e-mails which are filling up  
mail queue and you must wait few days until they are bounced. You  
cannot simply delete them because, if you do, sender won't know it's  
undeliverable and will send something to that address again in the  
future.


Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

Emanuel
Hello everyone,

my question arose because of a user on my server who sent to many
recipients without MX, then the mail was queued until the expiration time:

bounce_queue_lifetime = 5h

the idea was to reject emails manually with the error message that returned:

Example:

│Message: 06CB318005A26 │
│From..: "Rene Alvarado" <[hidden email]> │
│To....: <[hidden email]> │
│Subj..: SALDO PENDIENTE │
│Status: connect to impresosms.com[45.204.127.107]:25: No route to host

Regards,

El 15/1/20 a las 16:47, [hidden email] escribió:

>
> Citát Wietse Venema <[hidden email]>:
>
>> [hidden email]:
>>>
>>> Cit?t Wietse Venema <[hidden email]>:
>>>
>>> > Emanuel:
>>> >> Hello,
>>> >>
>>> >> It's possible bouncing email manually with the ID in the queue?
>>> >>
>>> >> In the documentati?n from de the command postqueue or postsuper i
>>> not
>>> >> find any information.
>>> >
>>> > That's because bounce by ID is not supported.
>>> >
>>> > You can bounce all mail for a specific recipient or a specific domain
>>> > with a transport map.
>>> >
>>> > /etc/postfix/main.cf
>>> >     transport_maps = hash:/etc/postfix/transport
>>> >
>>> > /etc/postfix/transport
>>> >     example.com                 error:text why mail is bounced
>>> >     [hidden email]      error:text why mail is bounced
>>> >
>>> > Instead of hash: you can use any Postfix darabase type.
>>> >
>>> > This also prevents the Postfix SMTP server from accepting new email
>>> > for that recipient or domain.
>>> >
>>> > A postsuper 'bounce' option would require
>>> > - Must be invoked by root.
>>> > - Drop privileges down to the postfix user.
>>> > - Lock the queue file for exclusive access.
>>> > - Either set a new flag in the queue file that the message must be
>>> bounced,
>>> > - Or for each recipient in the queue file send 'why mail is bounced'
>>> >   to the bounce daemon.
>>> >
>>> >     Wietse
>>>
>>>
>>>
>>> But it would be REALLY usefull feature, i was searching for such thing
>>> some time ago too.
>>
>> Why? Someone was drunk and sent a bad email? Is "postsuper -d" not
>> sufficient?
>>
>>     Wietse
>
>
>
>
> Use case: Users are sending undeliverable e-mails which are filling up
> mail queue and you must wait few days until they are bounced. You
> cannot simply delete them because, if you do, sender won't know it's
> undeliverable and will send something to that address again in the
> future.
>
>
--
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

Wietse Venema
In reply to this post by azurIt
[hidden email]:

>
> Cit?t Wietse Venema <[hidden email]>:
>
> > [hidden email]:
> >>
> >> Cit?t Wietse Venema <[hidden email]>:
> >>
> >> > Emanuel:
> >> >> Hello,
> >> >>
> >> >> It's possible bouncing email manually with the ID in the queue?
> >> >>
> >> >> In the documentati?n from de the command postqueue or postsuper i not
> >> >> find any information.
> >> >
> >> > That's because bounce by ID is not supported.
> >> >
> >> > You can bounce all mail for a specific recipient or a specific domain
> >> > with a transport map.
> >> >
> >> > /etc/postfix/main.cf
> >> >     transport_maps = hash:/etc/postfix/transport
> >> >
> >> > /etc/postfix/transport
> >> >     example.com                 error:text why mail is bounced
> >> >     [hidden email]      error:text why mail is bounced
> >> >
> >> > Instead of hash: you can use any Postfix darabase type.
> >> >
> >> > This also prevents the Postfix SMTP server from accepting new email
> >> > for that recipient or domain.
> >> >
> >> > A postsuper 'bounce' option would require
> >> > - Must be invoked by root.
> >> > - Drop privileges down to the postfix user.
> >> > - Lock the queue file for exclusive access.
> >> > - Either set a new flag in the queue file that the message must  
> >> be bounced,
> >> > - Or for each recipient in the queue file send 'why mail is bounced'
> >> >   to the bounce daemon.
> >> >
> >> > Wietse
> >>
> >>
> >>
> >> But it would be REALLY usefull feature, i was searching for such thing
> >> some time ago too.
> >
> > Why? Someone was drunk and sent a bad email? Is "postsuper -d" not
> > sufficient?
> >
> > Wietse
>
>
>
>
> Use case: Users are sending undeliverable e-mails which are filling up  
> mail queue and you must wait few days until they are bounced. You  
> cannot simply delete them because, if you do, sender won't know it's  
> undeliverable and will send something to that address again in the  
> future.

Why not set a smaller maximal_queue_lifetime?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

azurIt

Citát Wietse Venema <[hidden email]>:

> [hidden email]:
>>
>> Cit?t Wietse Venema <[hidden email]>:
>>
>> > [hidden email]:
>> >>
>> >> Cit?t Wietse Venema <[hidden email]>:
>> >>
>> >> > Emanuel:
>> >> >> Hello,
>> >> >>
>> >> >> It's possible bouncing email manually with the ID in the queue?
>> >> >>
>> >> >> In the documentati?n from de the command postqueue or postsuper i not
>> >> >> find any information.
>> >> >
>> >> > That's because bounce by ID is not supported.
>> >> >
>> >> > You can bounce all mail for a specific recipient or a specific domain
>> >> > with a transport map.
>> >> >
>> >> > /etc/postfix/main.cf
>> >> >     transport_maps = hash:/etc/postfix/transport
>> >> >
>> >> > /etc/postfix/transport
>> >> >     example.com                 error:text why mail is bounced
>> >> >     [hidden email]      error:text why mail is bounced
>> >> >
>> >> > Instead of hash: you can use any Postfix darabase type.
>> >> >
>> >> > This also prevents the Postfix SMTP server from accepting new email
>> >> > for that recipient or domain.
>> >> >
>> >> > A postsuper 'bounce' option would require
>> >> > - Must be invoked by root.
>> >> > - Drop privileges down to the postfix user.
>> >> > - Lock the queue file for exclusive access.
>> >> > - Either set a new flag in the queue file that the message must
>> >> be bounced,
>> >> > - Or for each recipient in the queue file send 'why mail is bounced'
>> >> >   to the bounce daemon.
>> >> >
>> >> > Wietse
>> >>
>> >>
>> >>
>> >> But it would be REALLY usefull feature, i was searching for such thing
>> >> some time ago too.
>> >
>> > Why? Someone was drunk and sent a bad email? Is "postsuper -d" not
>> > sufficient?
>> >
>> > Wietse
>>
>>
>>
>>
>> Use case: Users are sending undeliverable e-mails which are filling up
>> mail queue and you must wait few days until they are bounced. You
>> cannot simply delete them because, if you do, sender won't know it's
>> undeliverable and will send something to that address again in the
>> future.
>
> Why not set a smaller maximal_queue_lifetime?
>
> Wietse



Because there can be legitimate situations where it is good to keep  
e-mails longer in the queue (full mailbox, temporary outage of  
recipient server [which can take days] etc.).


Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

Jaroslaw Rafa
In reply to this post by azurIt
Dnia 15.01.2020 o godz. 20:47:45 [hidden email] pisze:
>
> Use case: Users are sending undeliverable e-mails which are filling
> up mail queue and you must wait few days until they are bounced. You
> cannot simply delete them because, if you do, sender won't know it's
> undeliverable and will send something to that address again in the
> future.

Can't you just write a simple script that extracts sender and recipient from
the message in queue, deletes the message and sends an email to the sender
informing that the recipient address is undeliverable?
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

Wietse Venema
Jaroslaw Rafa:

> Dnia 15.01.2020 o godz. 20:47:45 [hidden email] pisze:
> >
> > Use case: Users are sending undeliverable e-mails which are filling
> > up mail queue and you must wait few days until they are bounced. You
> > cannot simply delete them because, if you do, sender won't know it's
> > undeliverable and will send something to that address again in the
> > future.
>
> Can't you just write a simple script that extracts sender and recipient from
> the message in queue, deletes the message and sends an email to the sender
> informing that the recipient address is undeliverable?

If the sender needs to be informed (i.e it's not malware or spam)
then it makes sense to return the message as undeliverable so that
here is no loss of information.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

Bill Cole-3
In reply to this post by Emanuel
On 15 Jan 2020, at 14:55, Emanuel wrote:

> my question arose because of a user on my server who sent to many
> recipients without MX

Perhaps you just need to add reject_unknown_recipient_domain to
smtpd_recipient_restrictions?

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

Viktor Dukhovni
In reply to this post by azurIt
On Wed, Jan 15, 2020 at 09:32:43PM +0100, [hidden email] wrote:

> >> > Why? Someone was drunk and sent a bad email? Is "postsuper -d"
> >> > not sufficient?
> >> >
> >> > Wietse
> >>
> >> Use case: Users are sending undeliverable e-mails which are filling up
> >> mail queue and you must wait few days until they are bounced. You
> >> cannot simply delete them because, if you do, sender won't know it's
> >> undeliverable and will send something to that address again in the
> >> future.

When you say "filling up mail queue" is that actually a problem, or just
something you could simply ignore with no ill-effect?  The mail will
bounce eventually after (by default) ~5 days.

> > Why not set a smaller maximal_queue_lifetime?

As Wietse suggests, you can typically set the queue lifetime a bit
shorter (perhaps 2 days, but generally not much shorter, allowing
remote sites to fix problems they did not notice immediately).
With 5 days, you can wait out an outage that lasts across a long
holiday weekend.  With 2 days, an outage that does not get noticed
until the next morning and takes a day to fix.

> Because there can be legitimate situations where it is good to keep  
> e-mails longer in the queue (full mailbox, temporary outage of  
> recipient server [which can take days] etc.).

Which is why on outbound Postfix instances I tend to set:

    delay_warning_time = 2h,

giving my own senders generally same day notice of email that'll likely
never make it, but retries continue for ~2-5 days.  In commercial
deployments serving more than a handful of users, I always separate
inbound and outbound processing into separate Postfix instances.
The inbound queue has the default "delay_warning_time = 0h", which
does not leak internal hiccups to outsiders.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

Noel Jones-2
In reply to this post by Bill Cole-3
On 1/15/2020 3:42 PM, Bill Cole wrote:
> On 15 Jan 2020, at 14:55, Emanuel wrote:
>
>> my question arose because of a user on my server who sent to many
>> recipients without MX
>
> Perhaps you just need to add reject_unknown_recipient_domain to
> smtpd_recipient_restrictions?
>


We've had problems with users mistyping domain names, such as
hotmal.com or aoil.com. And they ignore the delay warning message
because they still don't notice their typo.

As far as DNS is concerned these are real domains with A records, so
they don't fail reject_unknown_recipient_domain. Some of them
web-redirect to the expected page, others are web squatters.

But they don't run a mail service, so connections to port 25 just
time out, and the mail sits in the queue until $maximal_queue_lifetime.

I've kinda-solved this problem by adding error: transport map
entries for the more common typos my users land on.  I expect others
will have a different list...



hotmal.com    error:5.1.2 hotmal.com is not valid.  Maybe try
hotmail.com instead.
hotmail.org   error:5.1.2 hotmail.org is not valid.  Maybe try
hotmail.com instead.
hotmial.com   error:5.1.2 hotmail.com not hotmial.com
hotmai.com    error:5.1.2 hotmail.com not hotmai.com
hotamil.com   error:5.1.2 hotmail.com not hotamil.com
hotmaill.com   error:5.1.2 hotmail.com not hotmaill.com
wanado.fr     error:5.1.2 wanadoo.fr not wanado.fr
htomail.com   error:5.1.2 hotmail.com not htomail.com
hotemail.com  error:5.1.2 hotmail.com not hotemail.com
verizion.net  error:5.1.2 "verizion.net" is not valid - try verizon.net
msns.com      error:5.1.2 "msns.com" is not valid - try msn.com
aoil.com      error:5.1.2 try "aol.com" instead
gmial.com     error:5.1.2 try "gmail.com" instead
aol.com.com     error:5.1.2 try "aol.com" instead
cenurytel.net   error:5.1.2 did you mean "centurytel.net"?
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
cdomcast.net    error:5.1.2 try "comcast.net" instead
cherter.net     error:5.1.2 try "charter.net" instead
at.net         error:5.1.2 try "att.net" instead



   -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

@lbutlr
On 15 Jan 2020, at 15:12, Noel Jones <[hidden email]> wrote:
> We've had problems with users mistyping domain names, such as hotmal.com or aoil.com. And they ignore the delay warning message because they still don't notice their typo.

Then they get the bounce when the max queue expires.

The messages in the queue are not hurting anything and unless there are millions and millions of them, they are not worth manually handling (nor adding custom transport maps to “fix” user’s tyops).

If user's complain about message to invalid recipients not getting delivered then have an FAQ that clearly says that it is impossible to deliver mail to an invalid recipient, that they get a warning message, and that they get a bounce. If they ignore the warning message, they likely ignore the bounce as well.

Also, creating a transports map that says that the VALID hotmal.com domain is invalid is a terrible idea that will blow up when hotmal.com becomes a huge freemail system next week.

There is only so much diaper-changing you can do for your users.


--
"Are you pondering what I'm pondering?"
"Oh, I think so, Brain! But doing a clog dance in actual clogs will
        give me awful blisters.”

Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

@lbutlr
On 15 Jan 2020, at 16:11, @lbutlr <[hidden email]> wrote:
> There is only so much diaper-changing you can do for your users.

Sorry, one other thing I wanted to add.

You have no control over mail DELIVERY to any domain that is not under your control. Even if everything in the headers is perfectly correct and the recipient exists at the domain and the messages is sent to the right server and accepted, whether the message is DELIVERED is entirely out of your control.

As one famous example, at one point Verizon device that they could reduce their spam load by discarding all emails that originated outside the US. They did not reject the emails, they did not notify other the sender nor the recipient that the messages were not delivered, they simply discarded them.

There was absolutely nothing that any mail admin could do about this.

Similarly, my wife’s employer used to very often discard messages sent with attachments, including at times internal mail from department heads to employees. One year, no one got their W2’s (their ’solution’ was to send a link to the W2 pdf in the form http://compaydomain/SSN/2011-W2.pdf). Again, no bounce, reject, or notice to either sender or recipient. Which messages? Who knows? Do they still do this? No idea, my wife stopped having anyone send mail to her work account and now only gets internal mail (and lots and lots of spam, of course, since their IT department, as should be obvious from this story, is entirely incompetent at handling mail).

Something about this should be in your aforementioned FAQ as well.

Just because the Postal service delivers a letter to an address doesn’t mean the people there do not put the mail directly into the shredder.



--
Si Hoc Legere Scis Nimium Eruditionis Habes

Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

Michael Orlitzky-2
In reply to this post by Noel Jones-2
On 1/15/20 5:12 PM, Noel Jones wrote:
>
> We've had problems with users mistyping domain names, such as hotmal.com
> or aoil.com. And they ignore the delay warning message because they
> still don't notice their typo.

I can +1 this request, even if it's something I morally shouldn't need.

Sometimes while checking the queue for some other reason, I'll notice a
message that I'm sure won't be deliverable: typo domain, mailbox over
quota, moribund provider, etc.

I'd like to bounce these immediately as a courtesy to the sender.
Blacklisting typo domains is a (technically incorrect) losing battle,
and if the message is to a distribution list, then it's useful for the
sender to know that the recipient is dead.

Yes, they'd get the bounce anyway when the message expires. But if I've
already done the thinkative work to figure out that the message will
bounce, it's a win at zero cost to bounce it immediately.
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

Viktor Dukhovni
On Wed, Jan 15, 2020 at 07:16:30PM -0500, Michael Orlitzky wrote:

> I'd like to bounce these immediately as a courtesy to the sender.
> Blacklisting typo domains is a (technically incorrect) losing battle,
> and if the message is to a distribution list, then it's useful for the
> sender to know that the recipient is dead.

On the other hand, likely or existing typo-squatter domains, especially
if they (almost) match your own domain, or the domain of a client or
business partner, can be vehicles for costly data leaks.  A few
incorrect bounces may be quite acceptable collateral risk of preventing
known potential harm.

> Yes, they'd get the bounce anyway when the message expires. But if I've
> already done the thinkative work to figure out that the message will
> bounce, it's a win at zero cost to bounce it immediately.

This is tricky for multi-recipient mail, where different deferred
recipients may have different error reasons.  So overriding the error
message is generally wrong, you'd go with the errors already saved for
each recipient.

Therefore, if this were to be made possible, the right mechanism would
be to to somehow expedite message expiration, with normal processing
on message expiration happening earlier than it would otherwise.

This could be done by adding a place-holder record to the queue file,
that could be later atomically (one byte write) updated to indicate
that the message is administratively expired.  Such messages would
expire after the next delivery attempt and would not be deferred
again.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

azurIt
In reply to this post by @lbutlr

Citát "@lbutlr" <[hidden email]>:

> On 15 Jan 2020, at 15:12, Noel Jones <[hidden email]> wrote:
>> We've had problems with users mistyping domain names, such as  
>> hotmal.com or aoil.com. And they ignore the delay warning message  
>> because they still don't notice their typo.
>
> Then they get the bounce when the max queue expires.
>
> The messages in the queue are not hurting anything and unless there  
> are millions and millions of them, they are not worth manually  
> handling (nor adding custom transport maps to “fix” user’s tyops).


I don't agree with this. Yes, technically it isn't a problem but we  
(and for sure not alone) are using message queue size as a sign of a  
problem - if there are much more messages then usual, our monitoring  
software is notifying us. In most cases it is a sign of hacked account  
which is spamming - in about 50% of such cases, spammers are sending  
spam very slowly, so you cannot simply note it, that's why we monitor  
it. And that's why it is a problem when there are lots of messages  
which you cannot get rid of by any means.

Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

@lbutlr
On 16 Jan 2020, at 00:02, [hidden email] wrote:

> Citát "@lbutlr" <[hidden email]>:
>
>> On 15 Jan 2020, at 15:12, Noel Jones <[hidden email]> wrote:
>>> We've had problems with users mistyping domain names, such as hotmal.com or aoil.com. And they ignore the delay warning message because they still don't notice their typo.
>>
>> Then they get the bounce when the max queue expires.
>>
>> The messages in the queue are not hurting anything and unless there are millions and millions of them, they are not worth manually handling (nor adding custom transport maps to “fix” user’s tyops).
>
>
> I don't agree with this. Yes, technically it isn't a problem but we (and for sure not alone) are using message queue size as a sign of a problem - if there are much more messages then usual, our monitoring software is notifying us. In most cases it is a sign of hacked account which is spamming - in about 50% of such cases, spammers are sending spam very slowly, so you cannot simply note it, that's why we monitor it. And that's why it is a problem when there are lots of messages which you cannot get rid of by any means.

If you have that many users sending mail to typed domains that you mistake it as a server issue then you have far more serious user issues than most people. And chances are whatever you do the user is going to continue to be confused and require personalized handholding “Yes, we know you’re just sending the mail from your address book/contacts list, but you are not checking that the email address is actually correct, are you? Oh, see, your MUA — er, mail program thingy, isn’t even SHOWING the email address you are sending to.”

Anyway, as Viktor pointed out, this is a coding nightmare because you have to account to the multi-recipient mail.

This is not a technical problem requiring a technical solution, this is a user problem requiring a user solution. If your users are ignoring delay messages, that is a user problem.

You can certainly write a script fairly easily to parse the mailq, find the messages that you consider problematic, delete them, and then generate a mail from the system (that your user will evidently ignore) saying "these were not delivered, they appear to have invalid email addresses" and then list the messages.

Isn’t this a much better solution than trying to write some bounce processing ability into postsuper?

Also, when I try to send an email to hotmal.com I get the following:

postfix/smtp[53472]: 47yz7m5Jj2zg4gL: to=<[hidden email]>, relay=none, delay=0.29, delays=0.06/0/0.22/0, dsn=5.1.0, status=bounced (Domain hotmal.com does not accept mail (nullMX))

So, there is nothing in the mailq and the message bounces immediately:

> This is the mail system at host mail.covisp.net.
>
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to postmaster.
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
>                   The mail system
>
> <[hidden email]>: Domain hotmal.com does not accept mail (nullMX)

So perhaps THIS is the issue on your server, you are not respecting nullMX replies?



--
A is for AMY who fell down the stairs B is for BASIL assaulted by
        bears

Msd
Reply | Threaded
Open this post in threaded view
|

Re: Bounce mails manually

Msd
In reply to this post by Viktor Dukhovni
> Which is why on outbound Postfix instances I tend to set:
>
>     delay_warning_time = 2h,

I'm interested by this functionality but I don't want the external
senders to be informed of local delivery problems.
And setting 2 postfix instances seems heavy for a small email server.

Is it possible to set the delay_warning_time and confirm_delay_cleared
parameters in the master.cf file for submission only ?
Given http://www.postfix.org/smtpd.8.html, I think no.

But is it something conceivable ?


Guillaume

Le 15/01/2020 à 22:56, Viktor Dukhovni a écrit :

> On Wed, Jan 15, 2020 at 09:32:43PM +0100, [hidden email] wrote:
>
>>>>> Why? Someone was drunk and sent a bad email? Is "postsuper -d"
>>>>> not sufficient?
>>>>>
>>>>> Wietse
>>>>
>>>> Use case: Users are sending undeliverable e-mails which are filling up
>>>> mail queue and you must wait few days until they are bounced. You
>>>> cannot simply delete them because, if you do, sender won't know it's
>>>> undeliverable and will send something to that address again in the
>>>> future.
>
> When you say "filling up mail queue" is that actually a problem, or just
> something you could simply ignore with no ill-effect?  The mail will
> bounce eventually after (by default) ~5 days.
>
>>> Why not set a smaller maximal_queue_lifetime?
>
> As Wietse suggests, you can typically set the queue lifetime a bit
> shorter (perhaps 2 days, but generally not much shorter, allowing
> remote sites to fix problems they did not notice immediately).
> With 5 days, you can wait out an outage that lasts across a long
> holiday weekend.  With 2 days, an outage that does not get noticed
> until the next morning and takes a day to fix.
>
>> Because there can be legitimate situations where it is good to keep  
>> e-mails longer in the queue (full mailbox, temporary outage of  
>> recipient server [which can take days] etc.).
>
> Which is why on outbound Postfix instances I tend to set:
>
>     delay_warning_time = 2h,
>
> giving my own senders generally same day notice of email that'll likely
> never make it, but retries continue for ~2-5 days.  In commercial
> deployments serving more than a handful of users, I always separate
> inbound and outbound processing into separate Postfix instances.
> The inbound queue has the default "delay_warning_time = 0h", which
> does not leak internal hiccups to outsiders.
>
123