Hector Santos wrote:
[2476(bis) 8.1 MAY add Sender]
I personally have concerns with any considerations that
introduce potential privacy concerns.
It's a point, enabling this option without prior consent of
the unhappy senders would be a very bad idea. OTOH if the
IESG allows the PRA abuse of v=spf1 policies this 2476bis
option could help to save at least some legit mails.
2476 "legalized" the strong authentication requirement
that removed all user privacy rights.
Same as it always was back to the days of Fido "sysops", as
"sysop" you're interested that users handle all fights they
might get in by themselves without your intervention. And
for that at least one of their addresses must be "correct".
The worst you can do is to promise "anonymous mail" when you
in fact have plain text log-files ready on your hard disks
and backups for everybody and his dog with a search warrant.
[snip]
I'm not sure what context is describe in which "hector" will
comment about this. Our server is a complete MSA/MTA/MDA
system
Yes, that's the point. Keith apparently envisions a system
where the functions MTA (incl. MX) and MSA are separated, so
you can always say "this box follows 2476 rules" (= MSA) and
"this other box follows 2821 rules" (= MTA).
And the "2821-rules" include stuff like "don't mess with the
mail header" (excl. trace header fields for the moment).
Since authorization is a prearrange relationship, return path
validation overhead is deemed unnecessary.
If an authorized user can still use any MAIL FROM he likes
you're in trouble as soon as one of your users is a zombie.
Unless you have the encrypted ID and a log-file, see above.
if ESMTP AUTH or IP relay checking is enforced for ISP users,
then port 587 is a mute point.
Still useful to bypass strange "block 25" schemes for roaming
users. Some ISPs confuse "block 25" with "proper abuse desk".
Bye, Frank