On Thu, Aug 05, 2004 at 10:05:54AM -0700, Hadmut Danisch wrote:
|
| MAIL FROM: <clerk(_at_)yourbank(_dot_)com>
SUBMITTER=criminal(_at_)superphishing(_dot_)any
|
| But how could the human reading the message tell that it came from
| superphishing.any and not from the bank? Today's MUAs are not ready
| for this extensions and I do not see how the SUBMITTER value would
| find it's way to the human reader.
You are correct that MUAs will need to change.
The SUBMITTER draft assumes familiarity with the core/PRA
document. Section 7.5 of that document reads:
7.5 MUA Implementers
When displaying a received message, an MUA SHOULD display the
purported responsible address as defined by this document whenever
that address differs from the RFC 2822 From address. This display
SHOULD be in addition to the RFC 2822 From address.
When a received message contains multiple headers that might be used
for the purported responsible address determination, an MUA should
consider displaying all of them. That is, if a message contains
several Resent-From's, a Sender and a From, an MUA should consider
displaying all of them.
http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt
I think we all agree that the above argument as an
antiphishing device is weaker than next-generation
cryptographic solutions.
The rationale was this: preferring the SUBMITTER value over
the MAIL FROM value was seen as making life easier for
forwarders. Requiring a PASS on SUBMITTER was seen as
making it possible to quickly attach reputation to bad
spammers. (In other words, a reputation system would be
expected to quickly list superphishing.any. This
expectation is justified by the fact that DNSBLs seem to
respond quickly, and RHSBLs should be able to respond just
as quickly.)
The common case is expected for SUBMITTER to not be present
in most spam, and so the check would operate against MAIL
FROM.
This reasoning is justified by:
4.1 Setting the SUBMITTER Parameter Value
SMTP clients that support the Responsible Submitter
extension MUST include the SUMBITTER parameter on all messages where
the purported responsible address, as defined in section 4 of
[SENDER-ID] differs from the MAIL FROM address. This includes
messages where the MAIL FROM address is empty or "<>".
http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-02.txt
I understand that to mean that the sending MTA has reduced
MAIL FROM:<K> SUBMITTER=<K>
to
MAIL FROM:<K>
and therefore a SPF check on K before DATA is sufficient.
The next sentence in the draft says:
SMTP clients SHOULD include the SUBMITTER parameter on
messages where the purported responsible address is the
same as the MAIL FROM address.
I move to rephrase that as:
SMTP clients MAY include the SUBMITTER parameter on
messages where the purported responsible address is the
same as the MAIL FROM address.