SM wrote:
What about senders from small emerging market countries having a very
hard time getting any widely accepted assurance group to vouch for them?
Also in more mature markets, not all of the existing companies and
universities running their own mail servers will be eager to spend
$5000/year on a vouch. In addition, the semantics of vouching is even
less specified than mc types. What kind of checks would a vouch-for
service operator carry out? I hope it will not be something similar to
getting a server TLS certificate... Will organizations like, say,
spamhaus.org issue _vouch records for free?
Dave CROCKER wrote:
Modern email receiving software includes a Handling Filter module that juggles a potentially rich array of assessments and attributes, associated with the message, before deciding whether to deliver it.
While that describes current practices correctly, it is at odds with
the concept of reliable mail transmission that the SMTP model (5321)
describes. In facts, mail sent to (some) giant ESPs may pass unnoticed
through recipients' mailboxes, if the sender didn't take care to
ensure deliverability by some obscure ESP-specific procedure. VBR
makes that behavior explicit. However, it provides no means to find
out which vouch-for operators a given recipient trusts, except by
manually searching in a giant ESP's web site for policies or
statements referring that.
The "obvious solution" for those 2nd class senders is to use one of
the giant ESPs as a submission agent, so as to delegate the handling
of outgoing email to a transmitter with plenty of clout. This
distinction between 1st class senders and smaller MTAs might remind
the ADMD/PRMD classification. We may be better off providing a
protocol method for verifying in advance what is going to happen with
a given message. For example,
C: VHLO example.com VBR:mv=operator1:operator2:operator3
S: 551 we only accept VBR:mv=operatorA:operatorB:operatorC
lets the client know that its mail is not going to be delivered in
the recipient's primary folder. That way, a client can be configured
to attempt regular MX delivery first, and resort to its preferred
giant MSA only if necessary. (Who'd write such extension? Please, send
any specific follow-up to a more specific list.)
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf