ietf-asrg
[Top] [All Lists]

[Asrg] Re: Re: draft-duan-smtp-receiver-driven-00.txt

2005-05-10 15:27:42
You missed one more piece of information in the notification: a
limited subject header summarizing the contents.

A wonderful place to put a spam message and URL.

It says "limited subject header" above which can include restrictions
on placing URLs.
(I had mentioned this already earlier.)

1) Your regular contacts will typically be in the allowed class. If
you see a notification from your regular contact that is in the
unclassified folder, it is easy to tell it is a faked message and you
need not spend time on it.

This statement is not generally true. For example, the IP addresses of the
sending site's MTAs may have changed, or the sender may be roaming.

Its the sender that's is roaming, not the sending MTA -- I don't see
any problem. And if the sending MTA changes its IP address, the
currently used  IP-based blacklists and whitelists go for a toss
anyway. So its not a new problem here.

messages, they need to be in sync about state of outgoing message queue
(for example, shared file systems).

Gee, that's a good idea. Imagine a shared filesystem supporting the whole
email infrastructure for millions of customers!

Again, it said "for example" above. Its an engineering decision that
would be different for different situations that designers make every
day depending on the scale of the system. The point is to design the
MTA to fit the email architecture, not to design the email
architecture to fit the current MTA design. Else you are simply
putting the cart before the horse.

- Kartik

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>