At 12:05 PM 1/17/2008 +0100, Alessandro Vesely wrote:
David MacQuigg wrote:
Maybe we could show direct relationships with == and indirect relationships
with ~~ and "same ADMD" relationships as MTA1/MTA2. The situation we are
discussing is then illustrated as:
/ /====================\
Sender(s) ==> Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
/
Border (box67.com) (aol.com)
What I mean by a "direct relationship" is a contract, or at least a signup on
a website. As an example, my service box67.com acts as a Receiver and
Forwarder for an individual, Robert, who has asked us to forward his mail to
aol.com. Robert has an account at aol.com, so there is also a direct
relationship between him and AOL.
Thus, in case Robert's account at AOL provides for local storage you would
have written ~~> MDA/Recipient?
Or maybe ~~> MD Agent ==> MUA/Recipient
-- MUA: Mail User Agent - a program running on a Recipient's personal
computer, handling mail submission and retrieval.
The MDA (or MD Agent, if we want to make a distinction between machine-level
and administrative-level terms) is normally part of the Mail Handling System,
separate from the Recipient, an individual in our discussions so far.
I still have problems with forwarding from MDA. Scripts or similar means to
(conditionally) forward messages are in a different position w.r.t. the
Receiver/Forwarder mainstream.
In facts, we can envisage some special behavior that the forwarding MTA may
accomplish in order to honor any specific agreement that encompasses
forwarding mail. However, a send mail command issued in a different context
may revert to the default MTA behavior. Or do we mean that the "direct
relationship" should affect _any_ mail exchange from box67 to that Recipient
along that path?
At 06:39 AM 1/17/2008 +0100, Frank Ellermann wrote:
The forwarder accepted the mail for some reasons, therefore he
is 100% responsible for it. If he doesn't like that, a valid
decision, he can reject it with "551" as explained in RFC 821.
Taking "251" decisions lightly is a failure of the forwarder -
it can't be the failure of later hops.
Of course "we" urge senders to help out with SPF PASS / FAIL
policies, allowing receivers (or here forwarders) to avoid the
2821bis NONE / NEUTRAL dilemma, but at the end of the day it's
the receiver (here forwarder) who accepted NONE / NEUTRAL mail.
Every Forwarder will set their own policies, but at box67.com, we don't send
DSNs. We reject whatever we can identify as forgery, and anything that is not
addressed to a valid Recipient, with a verified forwarding address on our
system. Having accepted the mail, we then deliver it either to the Recipient's
inbox (reputable senders), or to the Recipient's Quarantine, with an
appropriate score from our spam filter. If delivery fails, we suspend the
Recipient's account, and notify the Recipient via an alternate address. Only
if the Recipient fails to respond in a reasonable time, say 30 days, will we
terminate the account and delete the queued message. This is a very rare
occurrence, and we don't feel any obligation to notify the sender. Its no
different than if the Recipient disappeared, and the messages left in storage
at his MDA were deleted.
So far, we haven't had any problem with bounces. We don't send any, and we use
SRS to reject any "backscatter" coming our way.
-- 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=87162346-2a6ece
Powered by Listbox: http://www.listbox.com