Some notes on your proposal:
I. ASRG can not send documents protocols to IETF for "protocols", they
can only be or something that may become "informational" RFC
(Note: this is major difference between IRTF and IETF as was explained to me)
So your draft would have to go as individual submission especially since
asrg is not yet at the point of submitting any kind of documents.
II. What you're proposing is just like SRV RMX record. But srv records are
more advanced. Your point that DNS does not support it yet is not
appropriate - you expect sites to update software to support DS draft but
not update their dns software... I means if domain has to put this record
in, it might as well update dns software, not that complex and if somebody
is going to use the records, they'd have to update mail software, so I do
not see problem updating dns software. But really this is not a main issue
with the proposal...
III. As I already mentioned multiple times before this is typical
"RMX/Mail-From" style proposal which has the following problems:
1.You only authenticate MAIL FROM header but if "From:" is forged, that
is what user will see on their MUA, not MAIL FROM.
2.Breaks mailing lists (all have to be whitelisted - see:
https://www1.ietf.org/mail-archive/working-groups/asrg/currest/msg00762.html
You do have a section in the draft regarding mailing lists. But this
section is not correct. Correct would be to say that those usind DS
records MUST NOT send email to mailing list UNLESS mailing list has been
WHITELISTED ON THE SERVER. There just no other way to deal with mailing
lists (not if it supports DS records or not, does not matter).
3.Breaks majority of forwarding configurations. Again you have to
whitelist servers that may forward email to your server. Here the
situation is little worth, because spammers often put the use the same
domains in their from (ok, used to do it 2 years ago, now using free
mail services like yahoo or hotmail is more common)
4.Roaming users (like me on IETF conference) can not send email directly
and have to authentication with their "home" mail server. Actually this
is the list of my problems... I would really prefer to separete SUBMIT
and server<->server SMTP and require authentication on SUBMIT.
On Sat, 22 Mar 2003, Gordon Fecyk - Home wrote:
<http://www.pan-am.ca/draft-ietf-asrg-dsprotocol-00.txt>
As I haven't yet submitted it to the IETF, the version number hasn't
changed.
The big question I was asked two weeks ago was: "What selfish reason do I
have for implementing this protocol?" Well, I've now provided several.
I've also added notes on mail forwarding, which is still going to be
affected. Mailing lists seem unaffected - every list I'm subscribed to
either has "[$LIST]-request@" as the envelope sender or some other envelope
sender for tracking delivery failures.
Finally I've added a note about RFC 2821 section 7.1. That section says how
efforts like mine remove otherwise useful functionality. I've tried to
address that.
--
PGP key (0x0AFA039E):
<http://www.pan-am.ca/consulting(_at_)pan-am(_dot_)ca(_dot_)asc>
What's a PGP Key? See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg