> I still say RFC 821 requires it...
Well, you'd better start looking at MTAs released between 1982 and
today...you'll see that it was never acted upon as a requirement per
821, and was certainly not a barrier to entry in the standards-based
MTA world.
> The last line, "in some cases it may be further processed and
> transmitted by another mail system," is exactly my case -- fetching
> messages with getmail and passing them to TMDA to possibly send a
> challenge-response.
Those "some cases..." are simply cosmetic in the RFC, describing a
range of gatewayed applications (that's the kind of commentary that
older RFCs suffer from) without positing any functional mandate. But
that's not your situation, anyway. The messages in your case are
"delivered to the destination user," by the widely accepted definition
of local mailbox delivery. They only resume/restart mail-like
transport when you trigger a download.
> But to whom does TMDA send the challenge response? If the original
> e-mail was sent to a user on an IMail server, and the user is a
> member of a mailing list such as this one, we would have problems.
To be honest, I do not have much sympathy for anything that breaks C/R
systems, since they are broken to begin with, IMO and E (and the O and
E of huge numbers of other mail admins). The archives of this list
have a catalog of the traditional objections.
But more to my point, systems that attempt to reinvent SMTP without
actually being implemented as part of the SMTP process (as MTA
extensions or plug-ins) have no reasonable expectation of integration
with SMTP envelope information. This is why C/R fails, while
auto-whitelisting and other anti-spoofing technologies such as SPF
acknowledge the primacy of the SMTP transport and plug in at that
level.
I'm not really sure if you're designing a commercial system that is
derailed by the existence of IMail installations--in which case, why
not just say it doesn't work with IMail servers--or a particular site
deployment, in which case Declude Junkmail or another SendName can
readily add the information.
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
