At 10:49 AM 2/2/2008 +0100, Alessandro Vesely wrote:
David MacQuigg wrote:
What I was really
trying to say was let's not get involved in discussing solutions far
outside the scope of this group, as the details of signature-based
methods would certainly be.
IMHO the requirement may indicate to resolve the issue before the DATA
command, much like SPF.
Good point. Why didn't I think of this. :>( How about:
7) Forwarder authentication must be resolved before the DATA command.
This is related to cost (requirement 2), but can be an independent requirement.
After a message has been accepted, a wrong signature may permit to detect that
the message was a fraud. In that case we should question if the forwarder is
trustworthy. This kind of activity is important to properly maintain a
database of trusted forwarders - those who can get an authorization
automatically. No matter how well one examines a forwarder, it may still
become a spammer after having been examined. A forwarder who states *each and
every* message it forwards is signed by the original sender, makes it possible
to detect any attempt to originate spam pretending it is being forwarded.
If the original sender provides no signature, it is difficult to discover that
a trusted forwarder has become a spammer. We should devise a technique for
detecting if a message has not actually been forwarded. Checking a random
sample may suffice. Any idea?
Seems to me that once a forwarding relationship has been properly established
between two Agents, the only responsibility of the downstream Agent is to not
allow forgery of a specific connection ( Forwarder ID, RCPT Address ). If the
authorized Forwarder itself is bad, the Recipient must take action.
|-------- Recipient's Network ---------|
/
--> / --> Receiver/Forwarder ~~> MDA ==> Recipient
/
Border
If the downstream Agent does not accept this responsibility (my MDA does not),
the same result can be achieved by just keeping your mailbox address secret.
My MDA address has a few random digits known only to my Forwarders. It has
been operating for months with no problem.
-- Dave
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=93001336-f4d77d
Powered by Listbox: http://www.listbox.com