Chris Bannister <cbannis...@slingshot.co.nz> writes:
> On Sat, Oct 18, 2014 at 03:24:32AM +0200, lee wrote:
>>
>> Klensin Standards Track [Page 71]
>>
>>
>> RFC 5321 SMTP October 2008
>>
>>
>> if this address is null ("<>"), the receiver-SMTP MUST NOT send a
>> notification."
>>
>>
>> This clearly tells you that you *must not* drop or otherwise loose a
>> message once you have accepted it and that you *must* send a bounce when
>> the message can not be delivered.
>
> Is a bounce not some sort of notification. The above could easily be read as
> do nothing, don't bother the sender at all.
A bounce is a notification. You don't send one when you deny a message.
Since your MTA did not accept the message, it remains the responsibility
of the MTA or MUA on the sending side to inform the sender of the
message. Your MTA is not responsible for this because it did not accept
the message.
Only when you have accepted a message you can not deliver, you must send
a bounce.
>> Please do configure your MTAs accordingly.
>>
>> And that includes whoever runs this mailing list: When you block
>
> The MTA accepts them OK, no problem there.
>
>> messages, the senders must be informed that the delivery to the list has
>> failed. --- I cannot verify whether messages sent to this list have
>> been silently dropped.
>
> The policy of MLs or forums has got nothing to do with MTA
> configuration. The policy is implemented in either the mailing list
> software (mailman, majordomo, etc) or the forum bulletin board software.
Technically, yes. Practically, I'm sending a message which is to be
delivered to this mailing list. When the message is not delivered
correctly, I must receive a bounce. Whether the MTA processing
list-mail sends the bounce or the software that handles the mailing list
is irrelevant in this case.
If you want a technical argument: The software handling the mailing list
becomes part of the (operation of) the MTA and hence falls under the
same RFCs as MTAs do.
As a sender of a message, I can not know whether the list is handled via
entries in /etc/aliases, by an MTA that has special mailing-list
features built in, or by some other means. It entirely doesn't matter.
I merely expect correct handling of messages, and that includes bounces
being sent when delivery fails.
--
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us. Finally, this fear has become reasonable.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a94tj8oc....@yun.yagibdah.de
