Post by D. StussyI agree that's the point: We are NOT told that these are forged, so the
current standards tell us to treat them as NOT FORGED
It doesn't matter to me how you treat incoming messages.
Post by D. StussyAssuming the worst is contrary to the standards.
What do the standards say about what I'm allowed to assume? Please
quote and provide citations.
Post by D. StussyEven RFCs 5321 & 5322 say
we "need a reason" to refuse mail, not the lack of one.
RFC 5321 7.9. says
It is a well-established principle that an SMTP server may refuse
to accept mail for any operational or technical reason that makes
sense to the site providing the server.
Note carefully who gets to decide what constitutes a sufficient reason
to refuse mail. "any operation or technical reason" is an extremely
broad category.
Post by D. StussyA change to the standards or public policies (including "Best Current
Practices") requires an RFC to propose the change. There have been none.
Not sending sites mail they don't want and didn't do anything to
request is a very old policy.
Post by D. StussyPost by Jonathan KnightOr do you assume that if there's no SPF or DKIM then the domain is
prepared to accept backscatter?
If there's no SPF or DK record, that tells me that there are NO forgeries
Where is the RFC that redefines "forgery"? You want to change the
definition, you need RFC support. Or is RFC support only required
from those who disagree with you?
Post by D. Stussyand all mail was authorized from whatever source it came from.
Mail is not authorized by choosing not to implement this week's
FUSSP. Mail is authorized when the purported sender actually
authorizes it.
Post by D. StussyRemember that this says NOTHING about its spam status or other content
issues (e.g. viruses) which can lead to legitimate reasons to reject any
message.
See above: a legitimate reason for site X to refuse any message is
whatever *site X* decides is a legitimate reason. RFC 5321
specifically states that, as I quoted and cited. If you wish to
redefine "legitimate reason to refuse mail" you need to propose an RFC
to do so.
Post by D. StussyWhat's so difficult about deploying SPF (as a mail sender)?
I send to many people, a number of whom use forwarding services of
various types. Some of them are multi-hop, and I have no idea past
the first hop; therefore, I cannot create an SPF record that would
allow them to receive my mail (were they foolish enough to depend on
the result of SPF checks).
Post by D. StussyOne identifes all the sending points
"First, steal a chicken." That might not be possible (e.g. the
emission point is the mailswerver of whoever provides Internet access
to the hotel I'm staying at).
Post by D. StussyAs a mail receiver, all one needs to do is install any one of several
available plugins for various MTAs that check for SPF and DK records.
And if one is using a different MTA?
Post by D. StussyPost by Jonathan KnightSo the effort to reduce backscatter should move away from RBL's and
complaining about mail admins who return NDR's for over quota inboxes
and out of office messages and towards wider use of SPF and DKIM as that
looks to be the future.
Not possible. As I have previously demonstrated, a full mailbox and other
such errors can be minimized but NOT eliminated.
As others (including me) have shown, mailbox full and other quota
issues can be handled so as to avoid any such problems. The method is
to reserve space before accepting ("250") the message. If you can't
reserve the space, assume a mailbox full.
Post by D. StussyAlso, what does "vacation" responses have to do with this? If their
generators only see mail that has been through the checks (i.e. not forged
and not spam),
The checks don't show "not forged", they can only show "the methods I
use did not determine the message to be forged". Likewise, there are
no perfect spam filters, else the whole problem would have gone away.
Post by D. Stussythese autoreplies will be going to legitimate senders who
actually originated the inbound mail,
You aren't checking for that, because you can't.
Post by D. Stussyso how would they ever be considered backscatter?
They would be considered backscatter when they are.
Mail isn't magically "actually originated" by me when some spammer
forges my email address, no matter what protective technologies I
choose to implement or not implement. Mail is actually originated by
me when I, personally, perform the actual actions (^C^C) that cause it
to be sent.
Seth
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.