Question about "standards" WRT BATV and SAV

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Question about "standards" WRT BATV and SAV

Robert Fournerat
Please forgive me if this has already been discussed.  I saw
that in May of '06, Ralf, Victor, and Wietse had a small
discussion about BATV.  I know this is not a BATV list, but
there are people here with whom I tend to be more "policy
aligned".  So I beg some latitude and guidance.

BATV is mucking with the envelope FROM: address.  It appears
to me that when Postfix does a SAV, Postfix is trying to
verify the envelope's FROM: address (ie: the thing that BATV
modified).  Can someone please confirm that or correct me?

Unlike Ralf, regardless of what address_verify_sender value
I use, the SAV's fail.  Does this mean that the sender's
have misconfigured their BATV?  Does this mean that the senders
cannot use BATV if their ingress and egress servers are
different and share no BATV info?  Otherwise, how can BATV
possibly help with the backscatter problem?  Maybe I just
don't understand BATV (but I think I do).

So BATV offuscates the FROM: address.  This seems like a
TERRIBLE idea to me.  Isn't the BATV methodology making an
email look MORE suspicious by forging a FROM: address?
This seems like a very slippery slope.  Doesn't this
create more problems?  Is BATV even complient with the SMTP
RFC standards?

I know that some belive that SAV is evil because it enables
the possibility of being abused in a DOS attach against some-
one else.  I think SAV catches enough junk that it is worth
using.  For those that do not use SAV, have you devised
other methods that are as effective, and if so, can you share?

thanks,
Robert


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

mouss-2
Robert Fournerat wrote:

> Please forgive me if this has already been discussed.  I saw
> that in May of '06, Ralf, Victor, and Wietse had a small
> discussion about BATV.  I know this is not a BATV list, but
> there are people here with whom I tend to be more "policy
> aligned".  So I beg some latitude and guidance.
>
> BATV is mucking with the envelope FROM: address.  It appears
> to me that when Postfix does a SAV, Postfix is trying to
> verify the envelope's FROM: address (ie: the thing that BATV
> modified).  Can someone please confirm that or correct me?

yes, and this should work because the remote system is supposed to
accept addresses generated for the domain.
>
> Unlike Ralf, regardless of what address_verify_sender value
> I use, the SAV's fail.  Does this mean that the sender's
> have misconfigured their BATV?  Does this mean that the senders
> cannot use BATV if their ingress and egress servers are
> different and share no BATV info?

what would be the benefit of implementing BATV if inbound servers cannot
validate the generated addresses?
> Otherwise, how can BATV
> possibly help with the backscatter problem?  Maybe I just
> don't understand BATV (but I think I do).

with batv, valid addresses are "dynamic" and spammers can't guess them.
so backscatter will be rejected because it goes to an invalid recipient.
>
> So BATV offuscates the FROM: address.  This seems like a
> TERRIBLE idea to me.  Isn't the BATV methodology making an
> email look MORE suspicious by forging a FROM: address?
> This seems like a very slippery slope.  Doesn't this
> create more problems?

which problems are you talking about?

> Is BATV even complient with the SMTP
> RFC standards?

of course it is.
>
> I know that some belive that SAV is evil because it enables
> the possibility of being abused in a DOS attach against some-
> one else.  I think SAV catches enough junk that it is worth
> using.  For those that do not use SAV, have you devised
> other methods that are as effective, and if so, can you share?

Recipient validation (at the edge, during the smtp transaction) is the
recommended way. otherwise, discard/quarantine/hold/whatever instead of
bouncing.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

Wietse Venema
In reply to this post by Robert Fournerat
Robert Fournerat:
> Unlike Ralf, regardless of what address_verify_sender value
> I use, the SAV's fail.  Does this mean that the sender's
> have misconfigured their BATV?  Does this mean that the senders

Maybe it accepts the BATV-ed address only with MAIL FROM:<>.
http://www.postfix.org/postconf.5.html#address_verify_sender

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

Ralf Hildebrandt
In reply to this post by Robert Fournerat
* Robert Fournerat <[hidden email]>:

> BATV is mucking with the envelope FROM: address.  It appears to me that
> when Postfix does a SAV, Postfix is trying to verify the envelope's
> FROM: address (ie: the thing that BATV modified).  Can someone please
> confirm that or correct me?

Correct.

> Unlike Ralf, regardless of what address_verify_sender value
> I use, the SAV's fail.  Does this mean that the sender's
> have misconfigured their BATV?

Probably. Some major AntiSpam Appliance Verndor just recently (May
1st) fucked up their BATV generation.

> Does this mean that the senders cannot use BATV if their ingress and
> egress servers are different and share no BATV info?

I would think so.

> Otherwise, how can BATV possibly help with the backscatter problem?
> Maybe I just don't understand BATV (but I think I do).

BATV makes every envelope sender unique. Then you keep a list of VALID
& USED BATV sender addresses. Mail back to INVALID or UNUSED BATV
addresses gets rejected. It's easy.

"Only who went out may come back in"

> So BATV offuscates the FROM: address.  This seems like a TERRIBLE idea
> to me.  Isn't the BATV methodology making an email look MORE suspicious
> by forging a FROM: address?

No.

--
Ralf Hildebrandt ([hidden email])          [hidden email]
Postfix - Einrichtung, Betrieb und Wartung       Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
Confusion is permanent; its focus shifts with time.
              -- Karsten M. Self, confused, as usual.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

Jacqui Caren-home
Ralf Hildebrandt wrote:
> * Robert Fournerat <[hidden email]>:
>>So BATV offuscates the FROM: address.  This seems like a TERRIBLE idea
>>to me.  Isn't the BATV methodology making an email look MORE suspicious
>>by forging a FROM: address?
>
> No.

The implementations I have used/hit employ the addition of a key to the
address - ([hidden email] -> john/[hidden email]) - you can remove the
key to validate the address and can email the address without problem.

BUT if you send a bounce (MAIL From: <>) then you *must* provide the
BATV key associated with the header lines in the original email
which may include the subject line.

BATV engines can be very discriminating in analysing the message
encapsulated in the bounce to check the "signed" headers.
Badly formed bounces end to get rejected.

Part of the BATV model is timeouts encoded within the key
so that a bounce from two weeks ago is no longer valid.
Saying this I have had email take more than a week to return as
a negative delivery report so I would never use a timeout of
less than a month when installing BATV.

IMHO BATV is a good idea when *only* applied to well formed bounces.

Jacqui
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

Arne Hoffmann-2
In reply to this post by Robert Fournerat
Robert Fournerat wrote:
> Unlike Ralf, regardless of what address_verify_sender value I use, the
> SAV's fail.  

Showing some logs is always a good idea. If some implementation of BATV
isn't working, other people might be interested too.


> So BATV offuscates the FROM: address.  This seems like a TERRIBLE idea to
> me.  Isn't the BATV methodology making an email look MORE suspicious by
> forging a FROM: address?  

BATV doesn't 'forge' or 'obfuscate' the envelope sender. When using the
simple private signature (prvs) the local-part can easily be detagged by
skipping the first 12 characters.


> I know that some belive that SAV is evil because it enables the
> possibility of being abused in a DOS attach against some- one else.  

Well, at least the people at backscatterer.org think so. That's probably why
they blacklistet you (assuming netin.com is the domain you are talking
about).

arne@nell [~]$ dig 14.160.109.216.ips.backscatterer.org +short
127.0.0.2
arne@nell [~]$
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

Bill Cole-3
In reply to this post by Robert Fournerat
At 5:29 PM -0500 5/8/08, Robert Fournerat wrote:

>Please forgive me if this has already been discussed.  I saw
>that in May of '06, Ralf, Victor, and Wietse had a small
>discussion about BATV.  I know this is not a BATV list, but
>there are people here with whom I tend to be more "policy
>aligned".  So I beg some latitude and guidance.
>
>BATV is mucking with the envelope FROM: address.  It appears
>to me that when Postfix does a SAV, Postfix is trying to
>verify the envelope's FROM: address (ie: the thing that BATV
>modified).  Can someone please confirm that or correct me?

Yes. Properly done BATV requires the creation of an envelope sender
address that is a signed version of the base mailbox address. This is
done in the submission phase, by a MSA that is administrative
coordinated with the MX for the domain.

>Unlike Ralf, regardless of what address_verify_sender value
>I use, the SAV's fail.  Does this mean that the sender's
>have misconfigured their BATV?

It might.

It also might be that SAV is generally abusive and that you are using
it in a way that makes it more so, a way that is readily detectable
as bad and wrong by the sites you are abusing.

>Does this mean that the senders
>cannot use BATV if their ingress and egress servers are
>different and share no BATV info?

Absolutely. Whatever MSA is signing the base mailbox address needs to
be using a mechanism that is understood and verifiable by any
public-facing MX for the domain. The need to submit through a
specific MSA (or with a MUA that can sign on its own) is one of the
downsides for BATV, as it does not match the way many people are used
to operating.

>Otherwise, how can BATV
>possibly help with the backscatter problem?  Maybe I just
>don't understand BATV (but I think I do).

Maybe on one level...

>So BATV offuscates the FROM: address.  This seems like a
>TERRIBLE idea to me.  Isn't the BATV methodology making an
>email look MORE suspicious by forging a FROM: address?

Forging? Not at all. Generating? Yes indeed. A BATV address is a
tagged address in the same sense as the "plussed" addresses that
people have been using for a long time are tagged addresses. That a
tagged address gets deconstructed and possibly validated for final
delivery is a detail that should be ignored by systems that are not
trying to do final delivery for the address. Sites seeing mail with a
BATV envelope sender have no more reason to consider them suspicious
than they would with this message, whose 'From:' header will not
match its envelope sender by the time anyone reads it.

Also keep in mind the expansion of BATV: Bounce Address Tag
Validation. The entire point of BATV is to provide a pre-DATA means
to determine if a "bounce" (i.e. a DSN message) could possibly be
legitimate. The only envelope sender address that should ever be used
in offering mail to a BATV-signed envelope recipient address is '<>'
because a BATV address only is used as an envelope sender address
(not a header address) and only DSN messages (which MUST be sent with
<> as the sender) use the envelope sender of a message as their
envelope recipient.

>This seems like a very slippery slope.  Doesn't this
>create more problems?

How so???

Breaking SAV that is being done recklessly is not a problem. Quite
the opposite.

>  Is BATV even complient with the SMTP
>RFC standards?

Yes, in the sense that the SMTP spec is not actually relevant. What
BATV does is out of scope for RFC2821, but it is in scope for mail
submission (RFC4409). More importantly, address modification and
replacement in the submission phase has been a normal practice for a
very long time, and that has commonly included divergent
modifications of one or more of the envelope and header senders,
including per-message replacement/generation of the envelope sender
done solely to assure that bounces can be easily mapped to specific
messages sent to individual users. BATV isn't doing anything
particularly new or unusual, and incidentally isn't violating any
dictate of any RFC.


>I know that some belive that SAV is evil because it enables
>the possibility of being abused in a DOS attach against some-
>one else.

It is in fact the cause of such real problems. I've had my link
saturated by SAV attempts against addresses that never existed except
in forged spam.

>I think SAV catches enough junk that it is worth
>using.

 From the perspective of the site using it, perhaps it is. You're
splitting your spam detection load with sites that have nothing to do
with you other than having their domains forged in spam aimed at you.
What's not to like when you can make other people do your work?

You may want to consider that SAV is a relatively expensive form of
spam detection, even when you are offloading most of the work to
random innocent bystanders. A TCP connection and SMTP chat through
RCPT is a lot of effort just to reject a message and identify one bad
address that you'll probably never see again. Even ignoring the
fundamentally abusive nature of SAV, you probably want to avoid doing
it on more than a tiny fraction of your mail.

>  For those that do not use SAV, have you devised
>other methods that are as effective, and if so, can you share?

I cannot say for sure, since I don't use SAV.  I'm managing to
reject >99.5% of spam offered to my mail server without it and the
spam has made it through to my own mailbox in the past month has been
entirely immune to SAV: largely DKIM-signed junk from major freemail
providers, backscatter, and a few questionable cases where the
envelope senders validate as of this morning. That's very similar to
what I've seen with other systems I've worked with recently, none
using SAV. Putting SAV in a rational place in a layered spam
detection system might avoid having to do some expensive content
scanning, but it does not seem to me to really add much to the final
outcome.

As for how a strong spam control system is done, it is not one "magic
bullet" tactic, and every site is a little different in what tactics
are most workable and effective. That's why Postfix has so many
configurable features related to spam control.  Recipient validation
alone is usually the top winner, although it is a bit of a stretch
to call that a spam control tactic. After that, the CBL (and for
sites that are small enough or willing to buy a feed, Spamhaus Zen)
is almost always a very safe heavy hitter, . In the past year it has
also become much more widely feasible to reject on bad rDNS
(reject_unknown_reverse_client_hostname) and unqualified HELO names,
each of which are cheap enough to put ahead of DNSBL's and may split
the bulk of the zombie spam almost evenly with the CBL/Zen if used.




--
Bill Cole                                  
[hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

Bill Cole-3
In reply to this post by Arne Hoffmann-2
At 10:11 AM +0200 5/9/08, Arne Hoffmann wrote:

>Robert Fournerat wrote:
>>  Unlike Ralf, regardless of what address_verify_sender value I use, the
>>  SAV's fail.
>
>Showing some logs is always a good idea. If some implementation of BATV
>isn't working, other people might be interested too.
>
>
>>  So BATV offuscates the FROM: address.  This seems like a TERRIBLE idea to
>>  me.  Isn't the BATV methodology making an email look MORE suspicious by
>>  forging a FROM: address?
>
>BATV doesn't 'forge' or 'obfuscate' the envelope sender. When using the
>simple private signature (prvs) the local-part can easily be detagged by
>skipping the first 12 characters.

That is not quite so.

I know the current draft says that, but I am looking at a bunch of
mail from John Levine (the author of the BATV draft) plus a handful
from people at IronPort that all goes the other way, as described in
the first two versions of the draft.  That model is still
de-taggable, but it requires parsing rather than just byte counting.
Since John's qmail patch, IronPort, and the Sendmail milter use the
old model, and probably together make up the most widely deployed
BATV implementations, it isn't really the case that following the
current draft to detag a BATV address works in the world at large.
See http://mipassoc.org/pipermail/batv-tech/2008q2/000048.html

BATV implementations are still not really ready for widespread deployment.


--
Bill Cole
[hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

Mike Selner
In reply to this post by Wietse Venema
Wietse Venema wrote:
 > Robert Fournerat:
 >> Unlike Ralf, regardless of what address_verify_sender value
 >> I use, the SAV's fail.  Does this mean that the sender's
 >> have misconfigured their BATV?  Does this mean that the senders
 >
 > Maybe it accepts the BATV-ed address only with MAIL FROM:<>.
 > http://www.postfix.org/postconf.5.html#address_verify_sender
 >
 >     Wietse
 >

Hello,

I have address_verify_sender = <> and I use SAV (no flames please, I
have already read the thread and I think I understand the implications).

We see a significant number of envelope senders in the forms:

from=<prvs=SOMEUSERNAME=[hidden email]>  and

from=<SOMEUSERNAME/[hidden email]>

(and similar) where [hidden email] is the sender's address.
SAV probes with <> fail in both of these cases.

Mail from <> to [hidden email] is also rejected, though
from what I am reading here, this is due to their broken BATV
implementation.

We are getting a number of people who are not receiving mail because
the SAV never completes due to the sender's broken BATV.

Is someone willing to write a patch to SAV to parse the envelope
sender and then verify the "stripped" sender address
[hidden email]?

Or provide a better suggestion on how to SAV these scenarios, until the
senders / appliance vendors fix their broken BATV?

Whitelisting the sender domain (or omitting from SAV probes) is getting
tiresome.

Thank you
Mike


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

Victor Duchovni
On Sun, May 11, 2008 at 09:04:22PM -0500, Mike Selner wrote:

> Whitelisting the sender domain (or omitting from SAV probes) is getting
> tiresome.

In your shoes, I would stop using SAV, primarily because it is working
poorly for you.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

Arne Hoffmann-2
In reply to this post by Mike Selner
Mike Selner wrote:

> I have address_verify_sender = <> and I use SAV (no flames please, I
> have already read the thread and I think I understand the implications).
>
> We see a significant number of envelope senders in the forms:
>
> from=<prvs=SOMEUSERNAME=[hidden email]>  and
>
> from=<SOMEUSERNAME/[hidden email]>
>
> (and similar) where [hidden email] is the sender's address.
> SAV probes with <> fail in both of these cases.

Can you please give an example and/or show logfiles?

> Mail from <> to [hidden email] is also rejected, though
> from what I am reading here, this is due to their broken BATV
> implementation.

No, that is intended. Bounces are only accepted to the envelope from (until
that envelope from expires - it has a timestamp).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

mouss-2
In reply to this post by Mike Selner
Mike Selner wrote:

> I have address_verify_sender = <> and I use SAV (no flames please, I
> have already read the thread and I think I understand the implications).
>
> We see a significant number of envelope senders in the forms:
>
> from=<prvs=SOMEUSERNAME=[hidden email]>  and
>
> from=<SOMEUSERNAME/[hidden email]>
>
> (and similar) where [hidden email] is the sender's address.
> SAV probes with <> fail in both of these cases.
>
> Mail from <> to [hidden email] is also rejected, though
> from what I am reading here, this is due to their broken BATV
> implementation.

don't speculate.

Another possibility is that the remote site implements checks to block
backscatter.
Another one is that they do not accept mail from the null sender.

>
> We are getting a number of people who are not receiving mail because
> the SAV never completes due to the sender's broken BATV.
>
> Is someone willing to write a patch to SAV to parse the envelope
> sender and then verify the "stripped" sender address
> [hidden email]?

you just said that this one is also rejected!

>
> Or provide a better suggestion on how to SAV these scenarios, until
> the senders / appliance vendors fix their broken BATV?

the only fix is to stop using SAV.

>
> Whitelisting the sender domain (or omitting from SAV probes) is
> getting tiresome.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

Mike Selner
In reply to this post by Arne Hoffmann-2
Arne Hoffmann wrote:

> Mike Selner wrote:
>  
>> I have address_verify_sender = <> and I use SAV (no flames please, I
>> have already read the thread and I think I understand the implications).
>>
>> We see a significant number of envelope senders in the forms:
>>
>> from=<prvs=SOMEUSERNAME=[hidden email]>  and
>>
>> from=<SOMEUSERNAME/[hidden email]>
>>
>> (and similar) where [hidden email] is the sender's address.
>> SAV probes with <> fail in both of these cases.
>>    
>
> Can you please give an example and/or show logfiles?
>  

mail is being sent from [hidden email] to [hidden email]

postfix/smtpd[92591]: NOQUEUE: reject:
  RCPT from smtp2.EXAMPLE.COM[198.89.160.70]:
  450 4.1.7 <prvs=MS.XXXX=[hidden email]>:
  Sender address rejected: undeliverable address:
  host smtp3.EXAMPLE.COM[12.20.127.40] said:
  550 #5.1.0 Rejected by bounce verification. (in reply to RCPT TO
command);
  from=<prvs=MS.XXXX=[hidden email]> to=<[hidden email]>
proto=ESMTP    
  helo=<smtp2.EXAMPLE.COM>

To diagnose, I used telnet and smtpclient to manually probe their server
to simulate SAV:

An attempt to send from <> to [hidden email] or
prvs=MS.XXXX=[hidden email]
to either of their answering MX hosts 198.89.160.70 or 12.20.127.40
results in:
550 #5.1.0 Rejected by bounce verification.

This was tested a few minutes after receiving the above message to
minimize the effects due to BATV timeout.

Mail probe from <[hidden email]> to [hidden email]
does work.
So it appears to  be an issue with the null sender.
>> Mail from <> to [hidden email] is also rejected, though
>> from what I am reading here, this is due to their broken BATV
>> implementation.
>> No, that is intended. Bounces are only accepted to the envelope from (until
>> that envelope from expires - it has a timestamp).
>>    
I think they need to accept mail from <> for DSN and bounces.
Otherwise are they not RFC compliant?

I understand the comments made by others regarding the merits and evil
of SAV.
We do find it useful because of the benefits in most cases.

I would like to know if my interpretation is correct and I understand
the situation.

Does anyone have a similar issue, and hopefully a working solution or
suggestion?

It appears to me that the above sender's implementation is broken since
they do not accept mail from <>,
and skipping SAV may be the most practical option for this RECIPIENT.COM
domain.

Thank you
Mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

mouss-2
Mike Selner wrote:

>
> mail is being sent from [hidden email] to [hidden email]
>
> postfix/smtpd[92591]: NOQUEUE: reject:
>  RCPT from smtp2.EXAMPLE.COM[198.89.160.70]:
>  450 4.1.7 <prvs=MS.XXXX=[hidden email]>:
>  Sender address rejected: undeliverable address:
>  host smtp3.EXAMPLE.COM[12.20.127.40] said:
>  550 #5.1.0 Rejected by bounce verification. (in reply to RCPT TO
> command);
>  from=<prvs=MS.XXXX=[hidden email]> to=<[hidden email]>
> proto=ESMTP     helo=<smtp2.EXAMPLE.COM>
> To diagnose, I used telnet and smtpclient to manually probe their
> server to simulate SAV:
>
> An attempt to send from <> to [hidden email] or
> prvs=MS.XXXX=[hidden email]
> to either of their answering MX hosts 198.89.160.70 or 12.20.127.40
> results in:
> 550 #5.1.0 Rejected by bounce verification.
>
> This was tested a few minutes after receiving the above message to
> minimize the effects due to BATV timeout.
>
> Mail probe from <[hidden email]> to
> [hidden email] does work.
> So it appears to  be an issue with the null sender.
>>> Mail from <> to [hidden email] is also rejected, though
>>> from what I am reading here, this is due to their broken BATV
>>> implementation.
>>> No, that is intended. Bounces are only accepted to the envelope from
>>> (until
>>> that envelope from expires - it has a timestamp).    
> I think they need to accept mail from <> for DSN and bounces.

so you want them to accept backscatter just to make your SAV work?

> Otherwise are they not RFC compliant?


the error message suggests that they reject <> under certain conditions
("verification"). if this is true, then I see no compliance issue.

In particular, if they reject your SAV because they know that you do
SAV, then there is no compliance issue.

Another possibility is that they check the helo when they verify the
"bounce" and they then see that they did not send the message to your
domain (the domain your helo) but to recipient.com.

>
> I understand the comments made by others regarding the merits and evil
> of SAV.
> We do find it useful because of the benefits in most cases.

People who use challenge-response find it extremely useful...

If you really want SAV, then you should configure your system so as to
minimize the calls.

>
> I would like to know if my interpretation is correct and I understand
> the situation.
>
> Does anyone have a similar issue, and hopefully a working solution or
> suggestion?
>
> It appears to me that the above sender's implementation is broken
> since they do not accept mail from <>,

I did not see a proof for this. ask someone at the other side to send me
mail and I'll test that.

> and skipping SAV may be the most practical option for this
> RECIPIENT.COM domain.
>
> Thank you
> Mike
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about "standards" WRT BATV and SAV

Arne Hoffmann-2
In reply to this post by Mike Selner
Mike Selner wrote:

> To diagnose, I used telnet and smtpclient to manually probe their server
> to simulate SAV:
>
> An attempt to send from <> to [hidden email] or
> prvs=MS.XXXX=[hidden email]
> to either of their answering MX hosts 198.89.160.70 or 12.20.127.40
> results in:
> 550 #5.1.0 Rejected by bounce verification.
>
> This was tested a few minutes after receiving the above message to
> minimize the effects due to BATV timeout.

Is the host that you used for testing listed on ips.backscatterer.org? If
example.com is utilizing this list to reject bounces it would explain the
situation. Try testing from a host that is not listed.

> It appears to me that the above sender's implementation is broken since
> they do not accept mail from <>, and skipping SAV may be the most
> practical option for this RECIPIENT.COM domain.

... unless you want to maintain an extensive whitelist.
Loading...