Serge Knystautas wrote:
>
> Steve Brewin wrote:
> > There is a boundary case where the hostname in the received
> header cannot be
> > resolved. This used to always treat the mail as
> undeliverable. Now there's
> > an option to inject it. The fix just applied ensures that
> in this case, or
> > any future case, where the remote address or host cannot be
> determined
> > 127.0.0.1 /localhost are used and a Mail Attribute set to
> indicate the
> > condition. This avoids falling back to the original
> condition where we could
> > have the Mailet chain falling over.
>
> Interesting dilemma. Why not in the boundary case have it
> revert to the
> hostname of the mail server with the POP3 mailbox. To me it seems
> logical since we are effectively (in reverse) accepting email from
> there. We can then differentiate between a locally generated message
> and one that was retrieved from a (trusted) host.
I originally had the same notion as you, but then discounted it as...
1) We can differentiate already. Anything injected by fetchmail has one or
more Mail Attributes attached, including where it was fetched from. The
presence of the fetchedFrom Mail Attribute can be used to select mail from
all fetchmail mail stores for specialized fetch processing without having to
adjust the Mailet chain each time a mail store is added or removed. The
value of the Mail Attribute can be used to select mail for specialized
processing according to the mail store it was fetched from.
2) Relying on the hostname would not allow differentiation between...
a) Mail fetched from the mail server with the POP3 mailbox that
originated externally to that server that had an iffy received: header
b) Mail truly sent from that server, typically mail sent by the ISP.
3) Using the hostname of the mail server with the POP3 mailbox adds overhead
with no extra value. Matchers such as InSpammerBlacklist and
SenderInFakeDomain keep validating the same hosts. In fact, I was planning
to go further and suggest that matchers like InSpammerBlacklist and
SenderInFakeDomain skip the DNS lookups for 127.0.0.1/localhost, as the
result is a foregone conclusion.
What would be cool would be an IP address which could be uniquely identified
as denoting 'unknown', as that is what we are saying, and indeed what the
original <null> value was indicating right back at the beginning of this
story. I don't know of a designated IP address for this, does anyone if
there is one?
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
