David MacQuigg wrote:
Thus far, we have located a few ways to aid that task:
* whitelisting by MTA-specific (IP-based?) settings,
* the AUTH Parameter to the MAIL FROM command,
* SPF "i-am=" or similar modifiers in the DNS record.
Don't forget http://trusted-forwarder.org/ and Michael's
TENBOX proposal.
Good point. I found the latter at
http://www.gossamer-threads.com/lists/spf/discuss/28067
We could also add a "Standard Forwarding
Request" form, but I haven't given it any more thought than
just what I've written above.
However, the three added points describe techniques for
establishing relationships. The former three points apparently
address what happens during an SMTP transaction more closely.
-- Alias forwarding: forwarding an email and keeping its
original Return Address, rather than re-writing it using SRS.
-- SRS: Sender Re-writing Scheme http://openspf.org/SRS - A
method used by Forwarders to re-write the Return Address so
as to include the Forwarder's domain name.
For the terminology, I'd propose "vanilla forwarding" or
"plain mail forwarding", as opposed to "SPF-compliant
forwarding", be the latter SRS or otherwise.
I'm not sure aol.com should be labeled "MDA".
That is their role in this exchange. Of course, as a company
they provide a lot of other services, including Sender,
Transmitter, Receiver, Forwarder, Webhost, Domain Registrar,
Targeted Advertising ...
In addition, there is a second border after the
Forwarder(s). The latter is what makes it difficult for the
receiver to reuse spam knowledge gathered by the recipient.
??? There is a *direct* relationship between the Receiver and
the Recipient. The Recipient should send spam reports
directly to the Receiver, not AOL, not SpamCop, not anyone
who has no *first-hand knowledge* of the source of the spam.
This is where I get lost. We don't actually mount AOL's hard
disks on the Receiver host --which I'd call "direct". Formally,
we engage an SMTP (or LMTP) transaction with their server,
playing the transmitter's role.
These relationships are what make all the "borders" in the
MRN *secondary*. Unlike mail transfers crossing a Border,
transfers within an MRN are based on *prior arrangements*.
Fine.
-- MRN: Mail Receiving Network - includes all MTAs and
connections on the Receiver's side of the Border.
It is not clear if that is defined for each single transfer or
if an MRN is the union of all such MTAs for each recipient
currently valid at the target MTA. It is clear that MRN is
determined after the target domain, MRN(RHS). However, "prior
arrangements" might also be made for each specific user. In the
latter case an MRN is determined as a function of a specific
address, MRN(mailbox).
If I got it right, that parallels one difference between TENBOX
and trusted-forwarder.org.
-- Border:
the interface between the last MTA on the Sender's side, and
the first MTA on the Receiver's side of a mail transfer.
There is one and only one Border in a normal mail transfer
between unrelated parties on the open Internet.
Again, I tend to understand that as "unrelated as far as one
specific exchange is concerned."
Why is that forwarding different from secondary MX
transfer? (The last time I had a secondary MX it was on a
different ADMD in order to be on a different network --that
way, I did once receive a notification that my network was
unreachable.) Currently, I have no secondary MX in order to
avoid those difficulties. Besides unlisting/nolisting
tricks, I guess that is the current best practice about
secondary MXes. Isn't it?
-- Secondary MX: An email Receiver listed as a backup to the
main Receiver for a domain.
Secondary MXs are often exploited by spammers, who expect
that there will be less effective defenses on those machines.
Even if you have good defenses, you will see a flood of
attempts to spam those machines. I had a secondary MX for a
while, but dropped it for these reasons.
So did I. What I wanted to point out is that a secondary MX is
also part of an MRN. It also forwards mail attempting an SMTP
(or LMTP) transaction toward the primary MX (or one of them.)
Obviously, one difference is that secondary MXes don't change
the envelope recipients, while forwarders do that. Yet, those
who didn't give up secondary MXes (anyone out there?) had to
tackle the problems of how to configure mail acceptance and
propagate data for defensive mechanisms. The same problems that
we tackle now.
-------------------------------------------
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=86246330-6e595d
Powered by Listbox: http://www.listbox.com