1. Forum
  2. Usenet
  3. COMP.MAIL.SENDMAIL

  • NOTIFY=NEVER

    From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Grant Taylor on Wed Apr 28 17:55:35 2021
    Grant Taylor wrote:
    Is there a way to change the NOTIFY to NEVER for specific recipients
    when sending outgoing email?

    Can you be more specific? You checked the man page for mail
    submission right?

    -N notifications
    Tag all addresses being sent as wanting the indi-
    cated notifications, which consists of the word
    "NEVER" or a comma-separated list of "SUCCESS",
    "FAILURE", and "DELAY" for successful delivery,
    failure, and a message that is stuck in a queue
    somewhere. The default is "FAILURE,DELAY".

    If you have multiple RCPTs, then you would have to
    - use SMTP for mail submission
    - split the mail according to the intended notifications.


    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Wed Apr 28 11:41:08 2021
    Is there a way to change the NOTIFY to NEVER for specific recipients
    when sending outgoing email?

    It would be really nice if there was an access db option like the following:

    To:recipient-I-dont-care-about@domain.example NOTIFY=NEVER

    Even a milter would be better than what I'm dealing with now.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Wed Apr 28 13:29:01 2021
    On 4/28/21 11:55 AM, Claus Aßmann wrote:
    Can you be more specific?

    I'll try.

    I have a process that sends ... low value ... email to a defined list of specific recipients. It is expected that some of these emails will
    fail, and that's okay for this task.

    I'm about 95% certain that the messages are coming into the system via SMTP.

    I was hoping to find a way to set NOTIFY to NEVER for said defined list
    of specific recipients so that we don't get bounces. -- Quite
    literally, just try to send the message and never notify us if there is
    a problem. That's what logs are for. I don't /need/, much less /want/
    the DSNs (delay and eventual fail).

    You checked the man page for mail submission right?

    No, because I'm working with messages that come in via SMTP and I
    thought submission would be for "<bal> | (send)mail" type submission.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Grant Taylor on Thu Apr 29 04:44:46 2021
    Grant Taylor wrote:

    I was hoping to find a way to set NOTIFY to NEVER for said defined list
    of specific recipients so that we don't get bounces. -- Quite
    literally, just try to send the message and never notify us if there is
    a problem. That's what logs are for. I don't /need/, much less /want/
    the DSNs (delay and eventual fail).

    As you wrote: a milter can do that, but not a ruleset.
    Howver, I would use a filter to get rid of unwanted DSNs when they
    come back into the system. That way you can check the logs and when
    it happens too often: remove the address which generates the DSN
    from the list to stop bothering the RCPT.

    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Thu Apr 29 00:22:07 2021
    On 4/28/21 10:44 PM, Claus Aßmann wrote:
    As you wrote: a milter can do that, but not a ruleset.

    Are you aware of any milter that has that capability presently? Or
    would I be looking at rolling my own milter using well established methodologies?

    Howver, I would use a filter to get rid of unwanted DSNs when they
    come back into the system.

    Currently I /personally/ am the recipient of the DSNs and I'm just
    deleting between 1 and 10 a day. -- I'm now getting tired of them and
    feel like the system not sending the DSN in the first place might be a
    better option.

    That way you can check the logs and when it happens too often: remove
    the address which generates the DSN from the list to stop bothering
    the RCPT.

    That's not as viable of an option as you might hope. :-/

    Suffice it to say that this is a very specialized use case of a mesh of
    5-10 recipients / domains that willingly participate in something and
    that it's quite error prone. We are happy when it works, but we expect
    that there will be failures. Much like how we expect the Internet will
    drop packets. Just on a different scale. We don't /like/ it, but it is
    the nature of the beast and trying to change the beast will involve a
    LOT more work in a LOT of different ways. So ... we delete the 1 - 10
    DSNs a day.

    Hence why I'm looking for a way to avoid the DSN generation.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Grant Taylor on Thu Apr 29 13:03:11 2021
    Grant Taylor wrote:
    On 4/28/21 10:44 PM, Claus Aßmann wrote:
    As you wrote: a milter can do that, but not a ruleset.

    Are you aware of any milter that has that capability presently? Or

    No. Check your favorite search engine?

    would I be looking at rolling my own milter using well established methodologies?

    Probably.

    Currently I /personally/ am the recipient of the DSNs and I'm just
    deleting between 1 and 10 a day. -- I'm now getting tired of them and

    You don't filter your e-mail?

    You might want to look into setting a "mailing list" using the
    sendmail features, esp. wrt owner-LIST.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Jackson@21:1/5 to ml+sendmail@esmtp.org on Thu Apr 29 13:58:09 2021
    On 2021-04-29, Claus A?mann <ml+sendmail@esmtp.org> wrote:
    Grant Taylor wrote:
    On 4/28/21 10:44 PM, Claus A??mann wrote:
    As you wrote: a milter can do that, but not a ruleset.

    Are you aware of any milter that has that capability presently? Or

    No. Check your favorite search engine?

    would I be looking at rolling my own milter using well established
    methodologies?

    Probably.

    Currently I /personally/ am the recipient of the DSNs and I'm just
    deleting between 1 and 10 a day. -- I'm now getting tired of them and

    You don't filter your e-mail?

    +1.

    I'd just add a procmail filter rule.


    You might want to look into setting a "mailing list" using the
    sendmail features, esp. wrt owner-LIST.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Jim Jackson on Thu Apr 29 10:21:56 2021
    On 4/29/21 7:58 AM, Jim Jackson wrote:
    I'd just add a procmail filter rule.

    I make extensive use of procmail. wc is telling me 2334 lines of procmail.

    But, for this particular exercise, automating the clean up after
    (filtering the DSN) the fact is still less efficient than not making the
    mess in the first place (not sending the DSN).



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Thu Apr 29 10:19:25 2021
    On 4/29/21 7:03 AM, Claus Aßmann wrote:
    No. Check your favorite search engine?

    Probably.

    ACK on both accounts. That's what I thought was the case.

    You don't filter your e-mail?

    Oh, $DEITY, yes I filter the crap out of my email.

    But there is a difference in filtering after the fact vs not sending the messages in the first place.

    I'm contemplating fixing the underlying problem of not sending the DSN
    in the first place vs automating the cleanup / removal of the DSN after
    the fact.

    You might want to look into setting a "mailing list" using the sendmail features, esp. wrt owner-LIST.

    This has nothing to do with a mailing list. -- Each of a finite number
    of senders sends discrete messages to the other senders in a semi-deterministic* manner (A->B, A->C, B->C, A->D, B->A, B->C, D->A,
    ...) but it is definitely /not/ anything like a mailing list. If you
    must, think of some higher application layer process that sends
    ""messages (I use the term loosely) to other participants /via/ SMTP.
    Not unlike how AD supposedly can use SMTP to communicate.

    *Deterministic in that the contents of an incoming message will predict
    what the recipient will do, be it send an outgoing message to exactly
    one of the other participants or take some other external action.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Grant Taylor on Thu Apr 29 17:54:49 2021
    Grant Taylor wrote:

    This has nothing to do with a mailing list.

    Have you actually looked at the fine documentation as I suggested?

    2.6.3. List owners

    If an error occurs on sending to a certain
    address, say "x", sendmail will look for an alias
    of the form "owner-x" to receive the errors. ....

    Then you can simply discard mails to owner-x.

    Oh well, I guess you want to write a milter to implement your
    NOTIFY=NEVER idea.

    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Thu Apr 29 14:11:33 2021
    On 4/29/21 11:54 AM, Claus Aßmann wrote:
    Have you actually looked at the fine documentation as I suggested?

    I looked at the comments that you quoted.

    I'm not sure which specific document you are referring to. I just did a
    case insensitive recursive grep across Sendmail's source and don't see
    either what you listed in your first reply to my question or what's
    quoted below.

    What platform are you referring to the man pages on? Linux, FreeBSD,
    macOS, other?

    2.6.3. List owners

    Is this a general capability that Sendmail has? Or is it something specifically related to mailing lists?

    If an error occurs on sending to a certain
    address, say "x", sendmail will look for an alias
    of the form "owner-x" to receive the errors. ....

    I ask because the thought of Sendmail automatically falling back to
    owner-x when it can't deliver to x is slightly concerning to me. I
    would also have expected to have seen various hints of that behavior
    over the years. E.g. z is a bad recipient and what is this owner-z
    delivery attempt in logs (either the sending or receiving side).

    Please provide a better pointer to the documentation you're referencing.
    (See above.)

    Then you can simply discard mails to owner-x.

    Yes, that is a possibility. As is the procmail filtering.

    However, that's still cleaning up a mess after the fact and does nothing
    to prevent making a mess in the first place.

    Oh well, I guess you want to write a milter to implement your
    NOTIFY=NEVER idea.

    No, I don't /want/ to do it as in I'm not craving doing so.

    I do want to do /something/ -- I don't particularly care what -- to
    avoid making the mess in the first place, thus avoid needing to clean it
    up after the fact.

    Since I don't have control over the transient failures, I feel like the
    next best thing is to arrange it so that the failures don't make a mess
    via NOTIFY=NEVER.

    P.S. Let's try sending this again as a followup newsgroup post as
    opposed to an email. Sorry for the extra message Claus. -- I hate it
    when MUA updates change buttons and don't provide an option to change them.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Grant Taylor on Fri Apr 30 05:41:44 2021
    Grant Taylor wrote:

    I'm not sure which specific document you are referring to. I just did a

    doc/op/op.* -- the most important sendmal document.

    case insensitive recursive grep across Sendmail's source and don't see

    Unless you build op.txt grep probably won't find it, you
    would need a tool which can find text in ps/pdf files.

    I ask because the thought of Sendmail automatically falling back to
    owner-x when it can't deliver to x is slightly concerning to me. I

    Why? It's a well established practice wrt mailing lists.
    Moreover, people who can add aliases or users of that form
    hopefully know what they are doing.

    would also have expected to have seen various hints of that behavior
    over the years. E.g. z is a bad recipient and what is this owner-z

    well, reading the

    SENDMAIL(TM)
    INSTALLATION AND OPERATION GUIDE

    should give "various hints" about sendmail...

    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Fri Apr 30 01:35:05 2021
    On 4/29/21 11:41 PM, Claus Aßmann wrote:
    doc/op/op.* -- the most important sendmal document.

    I'm quite aware of that document. (See below.)

    Unless you build op.txt grep probably won't find it, you would need
    a tool which can find text in ps/pdf files.

    Ah.

    Why? It's a well established practice wrt mailing lists.

    Yes and no. Yes, it is a well established to have owner-<listname>@ or <listname>-owner@ email addresses. Likewise with a few other addresses.

    However, those addresses are added by the receiving list administrator.
    And to the best of my knowledge, humans had to tell their client to use
    those addresses.

    This is the no part. The idea that Sendmail would automatically fall
    back to trying owner-<something>@ in the event that <something>@ failed
    to send is the security exposure. E.g. I could flood <something>@ email address, running it over quota, thus causing the receiving system to
    refuse messages for <something>@. And here's the kicker, if Sendmail
    will automatically fall back and try to re-send the message to owner-<something>@, I could arrange for that to be configured on the recipient's system (say shared hosting / ISP / etc.) such that I would
    receive messages addressed to owner-<something>@ that were really
    intended for <something>@.

    Moreover, people who can add aliases or users of that form hopefully
    know what they are doing.

    Hopefully. But I wouldn't bet on it. Too many people just go through
    the motions they read about in a How-To.

    well, reading the

    SENDMAIL(TM)
    INSTALLATION AND OPERATION GUIDE

    should give "various hints" about sendmail...

    I've read a few different versions a few times over the last 20 years.
    I've got a copy printed and spiral bound to read (as of a year or so ago).



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Fri Apr 30 01:45:38 2021
    On 4/29/21 11:41 PM, Claus Aßmann wrote:
    doc/op/op.* -- the most important sendmal document.
    ...
    SENDMAIL(TM)
    INSTALLATION AND OPERATION GUIDE

    Having just re-read the List owners [1] and the larger The Alias
    Database [2] section, it seems as if the owner-* expansion form that you
    are talking about is only germane to expanding local recipients via the
    aliases database. Or am I mistaken in that understanding?

    So, with this assumption in mind, how is the owner-* expansion technique
    going to do anything for me when the problem address is on a remote system.

    Remember, the process that I'm talking about has nothing in any capacity
    to do with a mailing list, neither alias expansion, nor a local mailing
    list manager; e.g. Mailman.

    I'm dealing with a local process that sends an email via SMTP to the MSA
    on loopback from a valid local address (domain is in class w) to a valid
    remote address. As if you were sending a message from your ml (at)
    esmtp... address to my gtaylor (at) tnet... address and my system was
    offline for 36 hours because of a problem, hypothetically an extended
    power outage.

    [1] https://www.sendmail.org/~ca/email/doc8.12/op-sh-2.html#sh-2.6.3
    [2] https://www.sendmail.org/~ca/email/doc8.12/op-sh-2.html#sh-2.6



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Grant Taylor on Fri Apr 30 14:48:16 2021
    Grant Taylor wrote:

    This is the no part. The idea that Sendmail would automatically fall
    back to trying owner-<something>@ in the event that <something>@ failed

    You misunderstand the behaviour - that's not what the doc says.

    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Fri Apr 30 10:09:11 2021
    On 4/30/21 8:48 AM, Claus Aßmann wrote:
    You misunderstand the behaviour - that's not what the doc says.

    I agree that's not what the I.O.G. says. But it matches what I
    understood your earlier suggestion to be.

    See my reply 10 minutes after the one that you're replying to for clarification.

    My current understanding is that the owner-* trick won't work in my use
    case. Which I think is a good thing from a security perspective.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Grant Taylor on Fri Apr 30 16:18:49 2021
    Grant Taylor wrote:

    My current understanding is that the owner-* trick won't work in my use
    case. Which I think is a good thing from a security perspective.

    Ok, so just let's forget my suggestion - it's not worth to spend
    any more time on this.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Grant Taylor on Fri Apr 30 17:45:53 2021
    On 4/30/21 5:27 PM, Grant Taylor wrote:
    I'll try asking a different question.

    Does the owner-* technique work for non-local recipients?

    §2.6 — The Alias Database [1] — states that alias processing only
    happens on mailers with the A flag set.

    "After recipient addresses are read from the SMTP connection or command
    line they are parsed by ruleset 0, which must resolve to a { mailer,
    host, address} triple. If the flags selected by the mailer include the A (aliasable) flag, the address part of the triple is looked up as the key
    (i.e., the left hand side) into the alias database."

    §5.4 — M -- Define Mailer [2] — has this to say about the A flag.

    "Look up the user part of the address in the alias database. Normally
    this is only set for local mailers."

    The only mailer that I see with the A flag is the local mailer.

    As such, I'm fairly certain that the *smtp* and relay mailer will not do
    the owner-* alias expansion. Thus without specific information to the contrary, I'd expect that such owner-* alias expansion will not be done
    on an outgoing SMTP delivery.

    [1] https://www.sendmail.org/~ca/email/doc8.12/op-sh-2.html#sh-2.6
    [2] https://www.sendmail.org/~ca/email/doc8.12/op-sh-5.html#sh-5.4



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Fri Apr 30 17:27:24 2021
    On 4/30/21 10:18 AM, Claus Aßmann wrote:
    Ok, so just let's forget my suggestion - it's not worth to spend
    any more time on this.

    I'll try asking a different question.

    Does the owner-* technique work for non-local recipients?



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)