Your glib comments do not succeed in obscuring the fact that your product
trusts the standard SMTP headers, or it would never relay mail on to any
destination. If you don't like them, you're not alone, but you can't ignore
the validity of From:, To:, Sender: etc. relative to the x-Sender: or other
headers *designed* to go unprocessed.
Why do you deny that you're a vendor? I don't think that's a bad thing--you
developed and represent an excellent product. But just because it's
freeware doesn't mean you can divorce yourself from the product's reliance
on traditional SMTP usage. You advertise IMGate as an "anti-spam gateway,"
after all. So it *is* a gateway. And whether or not you "trust" headers
personally or are waiting anxiously for them to be phased out completely,
your product accepts them as paradigmatically authentic for mail routing.
This is the true difference between "trusted" and "untrusted" in my view.
When the message hits your Inbox, you can decide whether its routing history
is accurate or reliable. If you really don't trust information, it is
logged but otherwise ignored...on the contrary, though, my ISP's mail relay
will pass this traffic "To:" [EMAIL PROTECTED] because they
want to, not because there aren't better routing methods coming down the
pike, but because they *have* to to be compatible with MUAs and MTAs the
world over.
In sum, the decision to pass traffic is an implicit trust; full rejection of
authentication would imply that no traffic would ever be accepted by an
interface. And we both know an entire SMTP transaction can be forged, but
way back in 1982 on a private 'Net, this was not an issue. I believe that
oversight remains in all current implementations.
Sandy
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Len Conrad
> Sent: Thursday, October 26, 2000 11:02 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [IMail Forum] HEADER QUESTION
>
>
>
> >I disagree strongly with your contention that all headers are equally
> >untrustable. *Untrustworthy* they may be,
>
> not "may", are.
>
> >and always in need of better
> >authentication (a whole new protocol built around RFC 1113
> encapsulation,
> >perhaps?),
>
> IPv6 will help all security, and TLS is availabe now with postfix and
> other MTA's.
>
> >but there is an implicit trust placed in the standard headers
> >that you can't possibly deny.
>
> I didn't know that, damn it. Thanks. ( is this a debating / baiting
> exercise? )
>
> As a policy and based on my own ability, in seconds, to forge any
> header and send it anwyhere, from a spoofed ip, I don't, I can't,
> trust headers.
>
> I am FORCED to accept and deliver mail based on "RCTP TO:" and "MAIL
> FROM:" headers, but that doesn't mean I trust headers as authentic as
> a basis of anti-relay SMTP security.
>
> You set up Imail SMTP Security as "Relay for Local User/Hosts" and
> come tell us how much fun you have trusting SMTP headers.
>
> >To say that the To: header "[has] no value" is a bit silly for a
> >vendor of an SMTP relay.
>
> You must be referring to some other silly person, I don't vend an
> SMTP gateway anymore than I trust SMTP headers. But don't trust the
> body of this message, trust my sig. It's authentic and
> trustable. :-))
>
> Len
>
>
> http://BIND8NT.MEIway.com: ISC BIND 8.2.2 p5 & 8.2.3 T6B for NT4 & W2K
> http://IMGate.MEIway.com: Build free, hi-perf, anti-spam
> mail gateways
>
> Please visit http://www.ipswitch.com/support/mailing-lists.html
> to be removed from this list.
>
> An Archive of this list is available at:
> http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
