Greg A. Woods wrote:
So if the recipient address is never used for outgoing
mail, why in the world should any machine send mail to this address?
You seem to think that anything, agent or human, sending mail has to
have a mailbox address. That's simply not true.
It's simply not true that I think that. Agents may use an empty sender
address (actually many of them don't do that - interesting, huh?). But I
never saw a person using empty sender and cannot think of a reason why
somebody should do it. A person sending mail but not wanting to receive
any replies is sounds really weird to me.
Often there is no "recipient" user/mailbox in the first place for agents
which send messages with a null reverse path. That's part of what the
null reverse path is for to start with -- i.e. to be able to send mail
without having a valid, non-null, return address!
True. But agents sending to a receive-only mailbox most likely only
exist in controlled environments (like network management), where they
are explicitely told to send mail to this recipient.
4.5.5 Messages with a null reverse-path
[...]
Message Disposition Notifications (MDNs) [10]. All of these kinds of
messages are notifications about a previous message, and they are
sent to the reverse-path of the previous mail message. (If the
That's exactly what several people told you: [EMAIL PROTECTED] never sends out
mail, so he will never get valid mail from <>.
All other types of messages (i.e., any message which is not required
by a standards-track RFC to have a null reverse-path) SHOULD be sent
with with a valid, non-null reverse-path.
What I read here is: Don't use <> unless the RFC tells you so.
btw, you are still failing to give example
agents acting on the behalf of users, e.g. handling incoming messages to
users and sending automated replies to those messages, such as vacation
notices, should send those reply using a sender address that will be
returned to the same user.
And these agents only _react_ on mail they received by somebody.
This discussion is becoming really boring. Your arguments are weak, many
people showed you this, but you keep insisting and picking out the few
things you have something to respond with.
Summary:
1. rejecting <> is bad
That's not true, at least not in this generalisation. There are valid
reason to do so in special cases and local policies overrule any RFC.
2. Exim is bad because it makes rejecting <> too easy
Both is not true.
- Exim does not encourage users to do it and is not intended to break
smtp rules.
- One has at least to read and understand the spec to find out how to do
it (ACLs are not that trivial).
3. It's better to through away messages from <> at delivery time than to
reject them in the smtp rejection.
This is _so_ wrong. Delivering to /dev/null breaks any chance to
discover an error condition.
case closed.
And please stop CCing me, I'm on the list.
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
