Talk:Bounce Address Tag Validation
 | This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
| |||||||||||
The "BATV draft" link is broken. -- abfackeln 19:28, 11 November 2006 (UTC)
I just added the status part. Hopefully it's correct Mickyounger (talk) 23:34, 5 May 2008 (UTC)
- good point about the I-D being expired, but I think the "not accepted" gives the wrong impression. "has not been pushed through the publication process" is probably more accurate, but I've just changed it to note that the I-D is expired. Wrs1864 (talk) 00:06, 8 May 2008 (UTC)
Empty return address
[edit]Some legitimate e-mail gets sent with empty return address that
is not a bounce and therefore will not have the special tokens.
- How is this a failure in BATV or other related protocols? If an email with MAIL FROM:<> is sent to non-BATV-tagged email address, it's rejected, of course, because only BATV-tagged emails are supposed to be receiving emails with NULL sender. If it was meant that the system using this BATV-feature somehow barfed and does not generate BATV-tags in the envelope sender, but instead generates NULL sender, that also is not a failure in BATV or related protocols, but just a local configuration error.
- Bork (talk) 22:46, 11 September 2008 (UTC)
- BATV (and similar systems) are intended to try to filter out backscatter. However, when legitimate email gets sent with a null return address, it will look like backscatter. If the BATV enabled MTA rejects the email because it has a null return address but does not have BATV tags in the RCTP TO address, the you will get a false positive. From my talks with the draft authors, Dave Crocker in particular, false positives are something they really don't like and is not something they would intend to have if it could be avoided. Wrs1864 (talk) 23:46, 11 September 2008 (UTC)
- Not receiving a NDR some other, unrelated party generated is not a "false positive", like the current version of the article leads (some)one to believe.
- Bork (talk) 12:04, 12 September 2008 (UTC)
- Again, I'm not talking about an NDR, I'm talking about a regular email. For example, status reports on an order may well be given a null return address, either directly or via the NOTIFY=NEVER DSN option. Not receiving NDR some other, unrelated party generated is exactly what BATV is designed to eliminate. It is not designed to eliminate legitimate emails that are not bounces. Wrs1864 (talk) 15:32, 12 September 2008 (UTC)
- Not receiving a NDR some other, unrelated party generated is not a "false positive", like the current version of the article leads (some)one to believe.
- BATV (and similar systems) are intended to try to filter out backscatter. However, when legitimate email gets sent with a null return address, it will look like backscatter. If the BATV enabled MTA rejects the email because it has a null return address but does not have BATV tags in the RCTP TO address, the you will get a false positive. From my talks with the draft authors, Dave Crocker in particular, false positives are something they really don't like and is not something they would intend to have if it could be avoided. Wrs1864 (talk) 23:46, 11 September 2008 (UTC)