Chris Newman wrote:
This is incorrect. UAs will have access to the "MAIL FROM" address unless
an upstream system violated Internet standards. The final delivery agent
is REQUIRED to copy the "MAIL FROM" address into the "Return-Path"
header. Anything which doesn't is broken.
Chris, can you give us the exact location in an RFC that backs up your
assertion? I'm not sure it is required and I'm not sure you can ever
rely
on it's existence once the message have moved into the domain of the
MUA.
If you're right, my FreeBSD "out-of-the-box" installation is certainly
broken. The "P" flag required to generate the Return-Path header is
_not_
set for the local mailer by default. I don't know why, but the very
existence of this discrepency (the fact that it's optional) is enough
for
me to maintain that this header might not always be available. Period.
* even those that do will have to know to ignore (obviously) empty
MAIL FROM addresses - so do implementations that support this action
need exception handlers to deal with an invalid return address? Or
simply silently disregard them?
This is already defined in the standards. DSNs are not sent if there is
an empty "MAIL FROM" address, so "reject" would be equivlent to "discard"
in this case.
Ouch. Are you suggesting that the transfer from reject to discard would
be
done silently without giving a chance to the scripter to do something
else?
Agreed. But Sieve is designed for much more than just
UCE/UBE/SPAM/whatever. See my previous message for why a "bounce/reject"
action provides vital functionality.
Don't you think an automatic repetitive reject (whatever cause) can be
regarded as a kind of spam? What guarantee do you have that the receiver
of
the delivery rejection notification know how to handle such a message?
If the traffic is fluent, s/he might instead (wrongly but possibly)
decide
to order his filtering device to reject such stream of junk mail which,
as
you decribed above, might result in a silent discard because the lack of
an originator address.
We now have a stream of messages taking up network resources and with no
other purpose than using brute force (using automating tools) to
convince
a fellow netizen to stop sending messages. Some might regard that as
spamming as well.
My point is; when demanding new and powerful functionality in a tool
that
will become available to average end users, you should at least consider
the side (and less wanted) effects and consequences before having it
implemented. Just because it seem like a cool feature, it does not
necessary
equal to a useful one. Especially if you mix features from different
problem
domains in the same implementation entity. That is only going to cause
trouble.
--
Hälsningar/Regards
Tomas Fasth <tomas(_dot_)fasth(_at_)twinspot(_dot_)net>
Tel: +46-13-218-181 Cel: +46-708-870-957 Fax: +46-708-870-258
EuroNetics Operation, Mjärdevi Science Park, 58330 Linköping, Sweden
(TwinSpot Network is a subsidiary of EuroNetics Operation)