Talk:EHLO advertised URL

Terminology Correction

Original Text:

Client and server are also respectively named Transmitter and MDA according to MHS[2] terminology.

Model of system we are discussing:

|--- Sender's Network ---|           |-------- Recipient's Network ---------|
                                /
Author ==> MSA/Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
                              /
                           Border

The client is a Forwarder, not a Transmitter. A Transmitter has no relationship with a Receiver, whereas a Forwarder has an indirect relationship with an MDA, due to the direct relationship both have with the Recipient. This is important, because we are counting on that relationship to establish the forwarding agreement. Without this special relationship, you have an entirely different problem - the general problem of establishing trust between unrelated parties.

Establishing trust in a forwarding agreement requires only one simple check. Ask the Recipient if the agreement is OK.

This same misuse of the term Transmitter should be fixed on other pages as well.

--Macquigg 20:27, 30 December 2008 (GMT)

Terms

Thank you for spotting this. Forwarder is a much more natural term in this case, and it obviously is on the receiver side of the boundary. However, for this content page in particular, the client is not yet a Forwarder. I resorted to candidate Forwarder.

We need to distinguish between "boundary" and Border. Boundary can mean any line between two Actors (ADMDs). The Border is a special boundary, the only one between unrelated Actors.--Macquigg 20:27, 30 December 2008 (GMT)

Ask the Recipient

Asking the Recipient is going to be slow, as it involves human intervention. In that case, the message at hand will be relayed as usual.

I wouldn't worry about the delay. Setting up forwarding for most recipients is a very rare event, and it should be done carefully. Getting confirmation from the MDA, as well as precise feedback on exactly how the forwarding is being set up, is important for the recipient. The confirmation message can also include instructions and warnings about forwarded spam, etc.

The fundamental purpose of having a forwarding relationship is to allow mail from an otherwise untrusted source to be whitelisted for one recipient. Google.com may be sending spam to the entire planet, but if I have an account there and I want my mail forwarded to my mailbox at Yahoo, I will tolerate that spam (or complain to Google). Other Yahoo customers will not tolerate Google's spam.

We may have a fundamental misunderstanding on what Forwarding is all about. To me it means a relationship set up by the Recipient. This can be done without any involvement by the Forwarder or MDA, but it may help to have that involvement when the Recipient is not properly trained (almost always). Keeping the Recipient "in the loop" is important. I would go even further than an initial confirmation message. I would send a reminder once per month.--Macquigg 20:27, 30 December 2008 (GMT)

For regular legit cases, the user already opted in and possibly acknowledged a mail address check.

I must be missing something. Aren't we talking about setting up forwarding? Once a forwarding relationship has been established, it should not be necessary to do anything special, other than whitelist the mail from this forwarder to that recipient. --Macquigg 20:27, 30 December 2008 (GMT)

If we could go so far as to intercept double checks, then there is no reason to ask again, and we could grant access right away. However, that complicates things further. For known forwarders, the MDA should just grant the agreement.

I don't like having a separate mechanism for "known" good Forwarders. If we had such a mechanism, it should allow whitelisting *all* mail from that Forwarder. In other words, there is no need to distinguish a Forwarder from a Transmitter. The responsible domain is either trusted or not, and its mail is either whitelisted or spam filtered.--Macquigg 20:27, 30 December 2008 (GMT)

On the other hand, an ESP should provide a web page for setting email options, and the Recipient can go there to delete the agreement, possibly declaring that it was not legitimate. (The latter should affect the forwarder's reputation.)