I beleiv there are the following types of sender profiles that are
significant:
Originator
Domain owner edge MTA -> Recever edge MTA
Mailing List
Domain owner edge MTA -> Mailing list -> Recever edge MTA
Forwarder
Domain owner edge MTA -> Forwarder -> Recever edge MTA
Postcard
Postcard edge MTA -> Recever edge MTA
Bulk
Bulk edge MTA -> Recever edge MTA
Ignoring for a moment the various compound possibilities (originator ->
mailing list -> forwarder -> forwarder -> receiever) we have the following
consistency conditions for the various identities:
Originator:
RFC 2821 From Domain Owner Y
RFC 2822 From Domain Owner Y
RFC 2822 Sender --NULL-- -
Mailing List
RFC 2821 From Mailing List Y
RFC 2822 From Domain Owner N
RFC 2822 Sender Mailing List Y
Forwarder
RFC 2821 From Domain Owner N
RFC 2822 From Domain Owner N
RFC 2822 Sender --NULL-- -
Postcard [1]
RFC 2821 From Postcard Y
RFC 2822 From Domain Owner N
RFC 2822 Sender Postcard Y
Bulk [2]
RFC 2821 From Bulk Y
RFC 2822 From Client ?
RFC 2822 Sender --NULL-- -
Where:
Y MARID consistency check returns accurate PASS and FAIL results
N MARID consistency check returns accurate PASS results but FAIL is
not accurate
- Field not present, check not possible
[1] In the case that the postcard site is required to set Sender
[2] The bulk sender may not be able to get the client to configure their
DNS to include them
We get the following results:
2821 From
Pass - 100% accurate
Fail - Accurate unless forwarded
An attacker can set any 2821 From value they choose since it is only used
for bounces.
2822 Sender [if present]
Pass - 100% accurate
Fail - Accurate unless forwarded after sender added
2822 From [if Sender NOT present]
Pass - 100% accurate
Fail - Accurate unless forwarded or non compliant Postcard,
mailing list or bulk
An attacker can set a valid 2822 Sender value to their own domain to avoid
from checking. This is detectable in more recent clients.
I don't accept the 'efficiency' argument made for 2821 checking. Unless the
forwarder does SRS rewrite the check will fail. You then need to do the
forwarder recycle authentication which does not seem foolproof to me, and
certainly would require looking at the message body. I much prefer the
deterrence approach. If the spammer knows that certain processing is going
to take place on a message and that they will not be able to game it, they
will not waste their time and effort to send. Maybe an SMTP feature should
be defined for MARID so that an MTA can post what would be in effect a
'premises protected by electronic security' notice.
The edge cases MAY in principle be covered by additional authentication
mechanisms or by some form of accreditation mechanism. For example a list of
trusted forwarders, either global or local would be an accreditation
solution. A proof of sender mechanism would be an authentication solution. I
dislike the accreditation solution in this case since it implies giving
forwarders in effect aq 'wildcard' that allows them to impersonate anyone
they choose. It still requires a message hook to authenticate to (e.g.
Forwarded-By: or grovelling in headers). But we probably have to live with
that as an introduction issue.
In the case of forwarding relationships there are two issues to check:
1) Did the forwarder really send the message?
2) Did the forwarder accept spam?
Here I think we need some mechanism hook in any case. I would like to see a
header in the message path that tells me what each forwarder or relay did to
authenticate (and possibly) authorize) messages. I am less bothered about
the authorization since the receiver can redo that part but not the
authentication part.
The choices here seem to be induce the necessary data from the Received-By
headers or to define new headers. We may want to do a bit of both.
Conclusions:
A fail result at 2821 or 2822 level may indicate a forwarder
2822 checking requires postcards, mailing lists and bulk senders to
comply
Further action:
Define means that allows a forwarder to operate in compliance (e.g. SRS,
proof of sender)
Define compliance profiles for Postcard sites, Mailing Lists (done
actually)
It may be difficult for bulk senders to comply with requirements.
Phill
MARID.xls
Description: MS-Excel spreadsheet