On Fri, 2004-09-17 at 15:52, Markus Stumpf wrote:
On Thu, Sep 16, 2004 at 11:02:00PM +0200, Claus Färber wrote:
It can't break forwarding for bounce message because bounce messages
don't have a domain name in their 2821.MAILFROM.
Hmmm ... I can't find it anymore right now, but shouldn't SPF conform
bounces have a non empty envelope-sender, as a workaropund to prevent
spammers sending their messages with <> only?
The use of an empty reverse path dates back to RFC 1123 (Section 5.3.3)
which states that delivery failure MUST [with the standard implication
of the upper-case] use a null reverse path. This is to avoid bounce
messages bouncing to and fro across the 'net.
RFC 2821 is somewhat ambiguous (in section 3.7), but it also can be
interpreted in saying that notification messages MUST use an empty
reverse path.
It also states that implementations SHOULD use standard forms for such
messages (for instance Delivery Service Notifications: RFC 3464).
Yes, spammers do use an empty reverse path. But if the generators of
notifications always used a standard format (which should be processed
by the UA in attempt to correlate the notification with a sent message,
and therefore should never be presented to the user as a normal message,
therefore spammers would not use it), then it would be possible to
distinguish between legitimate and illegitimate uses of an empty reverse
path.
<grumble>
But the reality is that every email processing vendor seems to invent
their own format for bounces, which means that automatic processing is
not possible.
Which makes it a pain going through the mailbox for one's honeypot
addresses, trying to separate the bounces from the genuine rubbish.
</grumble>
But remember, SPF is _primarily_ about combating forgery. That, together
with other mechanisms, may help to stop spam. But the main benefit is
preventing people (and not just spammers) sending mail from addresses
which they are not entitled to use. ONe might say that a message with an
empty reverse path does not claim to be from anyone, therefore there is
no risk from forgery.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg