When the Front-Door is locked, they'll use the Back-Door left open.
RFC2821 MAIL FROM protections in general terms:
1) MAIL FROM checked before accepted:
a- caused by a virus - Good Reject
b- illicit spam technique - Good Reject
c- channel config error - Good Reject
d- other rejections - Good Reject
2) MAIL FROM checked after accepted, but before bounce:
a- caused by a virus, checked against prescribed channel - Bad Send
b- caused by a virus, checked with local-part signature - Good Drop
c- illicit spam, checked against prescribed channel - Bad Send
d- illicit spam, checked against local-part signature - Good Drop
e- channel config error, checked against prescribed channel - Good Send
f- other rejections - Good Send
3) RCPT TO <MAIL FROM> Bounce:
a- caused by virus, checked against prescribed channel - Bad Accept
b- caused by virus, checked against local-part signature - Good Reject
c- illicit spam, checked against prescribed channel - Bad Accept
d- illicit spam, checked against local-part signature - Good Reject
e- channel config error, checked against prescribed channel - Unknown
f- other rejections, checked against prescribed channel - Unknown
g- other rejections, checked against local-part signature - Good Accept
1)
MAIL FROM checks prior to acceptance is always good and will lower the
amount of bounce traffic that may occur for other reasons at subsequent
processes such as virus filtering or unknown recipient at subsequent
MTAs. Its all good.
2)
MAIL FROM checks after acceptance depends heavily upon the type of
checking. If the check is based upon a prescribed mail channel, then
due to a likelihood of this prescription being wrong, the bounce should
be sent. Proper practices should be able to avoid this problem, unless
the overhead is considered too great for the check to be done for each
message. If the check is based upon a local-part signature, then when
this check is made is less critical.
3)
The RCPT TO / MAIL FROM bounce depends fully upon the check made. It
also illustrates far end cooperation is not needed for the case where
the local-part signature is checked. Combined with a nounce, this check
can limit the number of replays somewhat, in addition to expiry
timeout. A channel check could help reduce a potential local-part
signature replay problem. This breakdown assumes illicit use will
ensure the defeat of a channel check.
-Doug