Err, I've said LMTP when I meant LMAP a couple times.
Mail servers already keep, and should keep Message-IDs.
I proposed:
Perhaps a better alternative to deprecating <> would be saying that
MTAs SHOULD bitbucket DSNs about email they know (thanks to LMAP
and/or Received/Message-ID headers) weren't sent from authorized
IPs/systems. Good/workable idea?
Expanding on this I see two schemes: A, B:
A)If we're going to use Message-IDs, then a new protocol is needed for
the MXes for a domain to have access to Message-IDs from all the
LMAP-authorized sending servers for the domains it handles. (a big hurdle!)
B)LMTP provides the list of all IPs that are authorized sources of email
that can result in legitimate DSNs. So if we can tell whether the DSN
is the result of such an email, great!
To be confirmed:
It's currently requried that every DSN include the source IP of the
initial email (including Received headers) that resulted in the DSN?
It's currently requried that it do so by including as an attachment the
email, including Received headers, that resulted in the DSN?
All legit DSNs seem to have the property that in the raw body (including
attachments) is a Received line containing the IP of an authorized
source of the initial email.
DSNs that are bounces of email I never sent don't.
All legit DSNs seem to have the property that the first Received line in
the attached email (or email header) is a Received line containing the
IP of an authorized source of the initial email.
DSNs that are bounces of email I never sent don't.
How can B be enhanced to keep spammers from directly sending out
DSN-mimicing spam with Received headers making it seem that the DSN was
legit?
What about the other uses for <>, beyond DSN (list needed!)
On 11/30/2003 11:52 AM, Claus Assmann sent forth electrons to convey:
On Sun, Nov 30, 2003, Hector Santos wrote:
Queuing design is par for the course. All software need to be queue ready
and all of them (worth their salt) are. Otherwise you do expect the target
...
No, the source MTA (the first server to get the message) still queues in
response to 4xx.
What did I say that implies eliminating queuing, Claus?
If the origination MTA sends to an intermediate MTA that can't reach the
destination MTA, the intermediate MTA would (in the scheme I'm
proposing) send a 4xx to the origination MTA, where it would be queued.
Good to hear you agree. Therefore this kills the proposal to not
use DSNs.
<and also said>:
PS: there are better ways to deal with MAIL From:<>
e.g., keep track of mails you sent and only accept DSNs for those.
This doesn't break anything in contrast to the proposals that are
coming up here again and again without considering why DSNs are
necessary and why <> has been chosen as sender address.
Sorry if I missed them.
Hector - I think your definition of false positive is wrong. WCSAP
bounces (err... refuses) MAIL FROM
addresses like abuse_autoresponder(_at_)rr(_dot_)com, and noreply(_at_)sourceforge(_dot_)net!
The former is arguably not a big deal, but the latter is a bit of a
showstopper.
If I read you right, you think blocking MAIL FROM these addresses isn't
a false positive. It is in my book.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg