On Fri, 3 Sep 2004 mazieres(_at_)gmail(_dot_)com wrote:
Correct me if I'm wrong, but I don't see anything in the current
drafts to suggest you could perform Sender ID checks after the fact.
I understand that *Caller ID* may have had such a stipulation. Thus,
as I read the drafts currently being considered, it is not possible to
implement Sender ID in an MUA. Does this mean we need a change?
The current drafts are inprecise and I've pointed out some of the conflicting
statements in one of previous posts. The marid-core draft in introduction
says that:
"This document described mechanism such that receiving MTAs, MDAs
and/or MUAs can recognize mail in the above category and take
appropriate action. For example, an MTA might refuse to accept a
message, an MDA might discard a message rather then placing it into a
mailbox, and an MUA might render that message in some distinctive fashion".
This statement can be understood to mean that MUAs would do SenderID check
but can also be understood that MUAs will take certain actions (displaying
verified email address, etc) based on secondary information from MTA but
not directly do authentication. However majority of people reading above
statement will probably understand it to mean that MUAs would do authorization
directly, so I'd like to request that this statement be changed to:
"This document described mechanism such that receiving MTAs and MDAs can
recognize mail in the above category and take appropriate action. For
example, an MTA might refuse to accept a message and MDA might discard
a message rather then placing it into a mailbox."
I think changing the document to support Sender ID checks after the
fact would be fairly controversial, however, both with ISPs, and with
small domain owners. If you want to do this, perhaps we need a macro
for the number days since 1970 when the message was received. (%{t}
is currently no good because it's only for explanations, it is in
seconds, and it is the current time, not the time at which the message
was received.)
It gets complicated, messy and leads to errors when you try to do ip
authorization after the smtp transaction and especially when you know
that serious amount of time passed from when it happened (serious is
anything more then 1 hour and even that is too much). It is also very
difficult to standartize this behavior and its outside scope of this
working group which is developing standard ONLY for MTA authorization
using DNS records.
The only program that has been successfull after the fact is Spamassin and
the reason is that it does it right after message is received by SMTP
server (within seconds usually) so there is no time interval and
spamassasin is setup specific with MTA it works with so it knows exactly
how that MTA will inform about which client just connected to it
and it knows there were no other email hop in between. Nevertheless,
as I understand it, spamassasin developers prefer to move system
where spamassasin is called directly from MTA (andthus within scope of
mail transaction) and not after the completion of transaction. That is
why it is now often called from sendmail milter and patches are available
for other MTAs.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/