OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: Question about "standards" WRT BATV and SAV

From: mouss (moussnetoyen.net)
Date: Mon May 12 2008 - 08:45:40 CDT


Mike Selner wrote:
>
> mail is being sent from MS.XXXXEXAMPLE.COM to GBYYYYRECIPIENT.COM
>
> postfix/smtpd[92591]: NOQUEUE: reject:
> RCPT from smtp2.EXAMPLE.COM[198.89.160.70]:
> 450 4.1.7 <prvs=MS.XXXX=0112a152aEXAMPLE.COM>:
> 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=0112a152aEXAMPLE.COM> to=<gbYYYYRECIPIENT.COM>
> 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 MS.XXXXEXAMPLE.COM or
> prvs=MS.XXXX=0112a152aEXAMPLE.COM
> 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 <sender_verificationMYHOST.COM> to
> MS.XXXXEXAMPLE.COM does work.
> So it appears to be an issue with the null sender.
>>> Mail from <> to SOMEUSERNAMEEXAMPLE.COM 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
>