C/R - can we do it right - Page 2

beq · 3 Dec 2007, 03:31 AM

Speaking of forwarder backscatter, do forwarders these days probe the destination server to see if it will accept a forwarded message, before accepting that message from the original sender? I'm thinking about the forwarder doing the probe after getting RCPT TO from the original sender (but before DATA), but perhaps the timing to do that is impractical?

I hear that the forwarder would also cache the list of good and bad recipients so as not to generate a probe for every message. So if it's impractical to complete a probe during the SMTP session from the original sender, I guess the forwarder can accept the first message and then just cache the accept/reject result at the destination server to use for subsequent forwardings in the near future.

Tuffmail told me this years ago, with their MX relay accounts and mailbox accounts I think (but I forget the details). Like any good provider they're very sensitive about generating backscatter. As I recall there are also other methods such as the MX relay account pulling the user list via LDAP from the destination server (like Exchange). And of course when the destination is another domain hosted at Tuffmail it's trivial to check accept/reject.

David MacQuigg · 3 Dec 2007, 03:12 PM

Quote:

Originally Posted by beq

Speaking of forwarder backscatter, do forwarders these days probe the destination server to see if it will accept a forwarded message, before accepting that message from the original sender?

We need to distinguish between sender's forwarders and recipient's forwarders. A sender's forwarder has an established relationship with the sender. There is no need for a probe, it just sends the message exactly as the original sender would, and notifies the sender if there is a problem.

A recipient's forwarder, like our box67.com, has an established relationship with its recipients. There is no need for a probe. If there is a problem, we suspend the recipient's account, and try to contact him via an alternative address.

Perhaps you are thinking of forwarders with no established relationship on either side. Those would be open relays, and they don't do anything by the book.

Scott Kitterman · 3 Dec 2007, 11:31 PM

Quote:

Originally Posted by hadaso

... I'm not sure it makes things clearer, but anyway the point is that most email users use shared transmitters and spammers can have access to these transmitters and can use them with all any domain owned by a user of these shared transmitters and pass SPF. Of course an ISP can police the use of their transmitters, but it's not clear that they have real interest in doing it. If they are big enough their users will not be blocked even if their transmitters send out lots of junk.

This issue was anticipated when SPF was being developed. It's in the SPF RFC security considerations:

http://www.openspf.org/RFC_4408#cross-user-forgery

In theory this is a risk, but it doesn't seem to happen much yet. BTW, my service is not vulnerable to this risk. I expect to start to pick up users from ISPs that don't police this once it's a more common problem.

http://tools.ietf.org/html/rfc5068 discusses this too.

Currently it's easy enough for spammers just to pick on a domain that doesn't have an SPF record they don't seem to bother with this. Once they do start to do this, then the market will respond.

beq · 4 Dec 2007, 05:20 AM

Quote:

Originally Posted by David MacQuigg

We need to distinguish between sender's forwarders and recipient's forwarders. A sender's forwarder has an established relationship with the sender. There is no need for a probe, it just sends the message exactly as the original sender would, and notifies the sender if there is a problem.

A recipient's forwarder, like our box67.com, has an established relationship with its recipients. There is no need for a probe. If there is a problem, we suspend the recipient's account, and try to contact him via an alternative address.

Perhaps you are thinking of forwarders with no established relationship on either side. Those would be open relays, and they don't do anything by the book.

But in either case isn't it in the forwarder's best interest when possible to avoid accepting a message where the forwarded RCPT TO will be rejected at the destination? Thus the forwarder avoids responsibility for the DSN.

Hmm I guess this becomes more of an issue with hosted relay services a la Postini filtering (especially in promiscuous mode), and when doing domain mapping/aliasing forwards? Sorry if my parlance is confusing, by relay I mean routing mail without modifying original RCPT TO (so not really "forwarding"). And by domain mapping I mean special catchall forwarding *@domain1 -> *@domain2 that retains the localpart.

Generating backscatter could be a big concern in these recipient-relationship cases, since the forwarder could be sending to many different unknown addresses at an external system (the recipient server).

David MacQuigg · 4 Dec 2007, 08:02 PM

I still don't see the forwarder as accepting any responsibility for sending a DSN. If a client asks us to "catch all" mail to any recipient name at their domain, and forward it to, for example, a "sales" address, we would expect them to deal with any delivery problems. The client might ask us to run an SPF check on any such mail, and look at that result before they decide to send a DSN.

We seem to have drifted off the topic of C/R systems and how we can do it right. Perhaps this issue of forwarder responsibility for DSNs should start a new thread.

theog · 4 Dec 2007, 08:21 PM

Quote:

Originally Posted by David MacQuigg

We seem to have drifted off the topic of C/R systems and how we can do it right. .

Might be because you can't do it "right" for some people... no matter what you will have the same inherent issues with any C/R system.

And some people think it is already “right.”

But carry on, it is fairly cool to see the same people saying the same things already posted in the thread you did not have time to read, but now they say things in nicer ways. You have accomplished a way to keep people civil.

David MacQuigg · 5 Dec 2007, 12:28 AM

We need more than just staying civil to have a productive discussion on this topic. We need to listen to the other side and dig out the underlying assumptions. Often these assumptions are unstated, and the argument over conclusions goes nowhere.

One assumption I've never seen stated, is that C/R cannot be done without bothering uninvolved persons. If someone is making that assumption, and I am not aware of it, any discussion of whether my proposal is "right or wrong" is worse than useless. It generates antagonism among folks who should all be on the same side vs the spammers.

By the way, I did read most of the earlier thread, but perhaps concluded too early that there was little productive discussion. My apologies to anyone who was offended.

beq · 5 Dec 2007, 12:51 AM

Quote:

Originally Posted by David MacQuigg

We seem to have drifted off the topic of C/R systems and how we can do it right. Perhaps this issue of forwarder responsibility for DSNs should start a new thread.

You're right, sorry about that

David MacQuigg · 6 Dec 2007, 03:41 AM

No problem. A short digression to a closely-related topic is welcome, and a challenge via the normal "bounce" method is a DSN of sorts.

3 Dec 2007, 03:31 AM	#16
beq Cornerstone of the Community Join Date: Jan 2005 Location: USA Posts: 895	Speaking of forwarder backscatter, do forwarders these days probe the destination server to see if it will accept a forwarded message, before accepting that message from the original sender? I'm thinking about the forwarder doing the probe after getting RCPT TO from the original sender (but before DATA), but perhaps the timing to do that is impractical? I hear that the forwarder would also cache the list of good and bad recipients so as not to generate a probe for every message. So if it's impractical to complete a probe during the SMTP session from the original sender, I guess the forwarder can accept the first message and then just cache the accept/reject result at the destination server to use for subsequent forwardings in the near future. Tuffmail told me this years ago, with their MX relay accounts and mailbox accounts I think (but I forget the details). Like any good provider they're very sensitive about generating backscatter. As I recall there are also other methods such as the MX relay account pulling the user list via LDAP from the destination server (like Exchange). And of course when the destination is another domain hosted at Tuffmail it's trivial to check accept/reject.

4 Dec 2007, 08:02 PM	#20
David MacQuigg Member Join Date: Aug 2006 Location: Tucson AZ Posts: 66 Representative of: Open-Mail.org	I still don't see the forwarder as accepting any responsibility for sending a DSN. If a client asks us to "catch all" mail to any recipient name at their domain, and forward it to, for example, a "sales" address, we would expect them to deal with any delivery problems. The client might ask us to run an SPF check on any such mail, and look at that result before they decide to send a DSN. We seem to have drifted off the topic of C/R systems and how we can do it right. Perhaps this issue of forwarder responsibility for DSNs should start a new thread.

5 Dec 2007, 12:28 AM	#22
David MacQuigg Member Join Date: Aug 2006 Location: Tucson AZ Posts: 66 Representative of: Open-Mail.org	We need more than just staying civil to have a productive discussion on this topic. We need to listen to the other side and dig out the underlying assumptions. Often these assumptions are unstated, and the argument over conclusions goes nowhere. One assumption I've never seen stated, is that C/R cannot be done without bothering uninvolved persons. If someone is making that assumption, and I am not aware of it, any discussion of whether my proposal is "right or wrong" is worse than useless. It generates antagonism among folks who should all be on the same side vs the spammers. By the way, I did read most of the earlier thread, but perhaps concluded too early that there was little productive discussion. My apologies to anyone who was offended.

6 Dec 2007, 03:41 AM	#24
David MacQuigg Member Join Date: Aug 2006 Location: Tucson AZ Posts: 66 Representative of: Open-Mail.org	No problem. A short digression to a closely-related topic is welcome, and a challenge via the normal "bounce" method is a DSN of sorts.