For the benefit of non-experts, I'll add a few definitions as I go, at least as
I understand the terminology. Let me know if I misunderstood anything. Maybe
Alessandro can collect these definitions for his Glossary page.
At 04:08 PM 1/14/2008 -0500, Stuart Gathman wrote:
On Mon, 14 Jan 2008, David MacQuigg wrote:
I don't know AOL's policies, but assuming they don't blacklist senders when
there is only a very small amount of spam leaking through, a less severe
Forwarder's policy might work. Perhaps Stuart could suspend just one
Recipient account on the first spam report. That will ensure the Recipient
knows not to do it again. Maybe the problem is absent-mindedness. The
Recipient should figure out how to segregate the forwarded mail from anything
else which he might report as spam. That may even require setting up a whole
new account just to receive forwarded mail. I've done this with all MDAs
that handle my own mail. Most accounts are free, so its not a big deal.
I did that at first. But, it is a pretty consistent statistical fact that
anyone who uses AOL mail is utterly clueless about email and computers in
general, and is incapable of understanding what the problem is and how
their actions are responsible. They might be (and usually are) smart in
other ways, but are computer idiots. So refusing to forward to AOL is the
only workable solution until AOL makes their blacklists available to
forwarders, or makes other arrangements.
AOL is a poster child for why the canard about how SPF "breaks forwarding"
is complete FUD. *Any* system that blocks the sources of spam
"breaks forwarding". And that is as it should be.
Yet AOL is a shining example of how a large email service, working for the good
of the community, can eliminate outgoing spam. They also publish an SPF record
(although not ending in -all as we would like). I think we should try to
figure out how to make SPF work with services like AOL and Yahoo, who are
*allies* in the war against spam, and not just keep saying that they and
everyone like them are wrong.
Both of these companies have eliminated their outgoing spam, even though that
adds nothing to their bottom line. They deserve some recognition of their good
work, at least among email experts.
Alias forwarding is broken, SPF or no SPF.
-- 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.
Yet AOL and others process tons of forwarded mail each day, and 99% of it
doesn't use SRS. So I guess we need a definition of broken.
It can only work when specifically configured by the receiver as well as
forwarder.
So how can we encourage forwarders and receivers to make these arrangements?
Right now we have small domains like Stuart's and mine making laborious
arrangements with companies like AOL and Yahoo, just to send *normal* mail to
their subscribers. That is a lot of work, much more than these companies
should expect of us. We need to make the process simple, and fully automated.
Maybe we could agree on a simple, standardized form, one for each Recipient
that wants their mail forwarded. After receiving a few of these forms, Yahoo
would figure out that it actually saves time on their end, compared to a bunch
of emails back and forth, and the five-page "exam" that they had me fill out,
proving that I knew how to manage a "mailing list".
The essential information in the form would be the Forwarder's domain name, its
authorized transmitter addresses, and the recipient's forwarding address.
'''STANDARD FORWARDING REQUEST \n To: _yahoo.com_ \n From: __box67.com_ \n IP
addresses: _see our SPF record_ \n Recipient _dmacquig(_at_)yahoo(_dot_)com_
has asked us to forward all his mail to his new address in your domain. Please
let us know when we may begin.''' Assuming Yahoo confirms the request with its
Recipient, this procedure seems airtight, i.e. no way a spammer can abuse it.
At 10:38 AM 1/15/2008 +0100, Alessandro Vesely 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. 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.
David MacQuigg wrote:
Well, using our new terminology, we should be able to simplify this
discussion.
/
Sender(s) --> Transmitter--> / --> Receiver --> Forwarder(s) --> MDA -->
Recipient
/
Border (Stuart) (aol.com)
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.
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*.
-- MRN: Mail Receiving Network - includes all MTAs and connections on the
Receiver's side of the Border.
-- 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.
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. In nearly three years, our primary
MX has been down only once, and that was 20 minutes for a pre-arranged service
upgrade. Hosting services are so cheap and reliable now, that secondary MXs
are just not needed.
That's not to say a busy domain doesn't need *multiple* MXs, but the difference
is that all MXs are configured identically, including the recipient database,
which is hard to replicate on a shared "secondary" MX.
-- 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=86050674-27ce0b
Powered by Listbox: http://www.listbox.com