To all that are using spamreview...
If it appears that spamreview is locking up it may be because it is trying
to load a large message and/or a large number of messages. To resolve the
problem make sure you have v1.0.12. If you don't, you can download it at
http://www.slsoft.com/spamreview.htm
>Is the following true:
>
>Incoming Mail
>
>%LOCALHOST% = %RECIPHOST%
>%REMOTEHOST% = %SENDERHOST%
>
>Outbound Mail
>
>%LOCALHOST% = %SENDERHOST%
>%REMOTEHOST% = %RECIPHOST%
Yes, that is correct.
-Scott
---
[This E-mail was scanned for viruses by Declude Virus (http://www
Is the following true:
Incoming Mail
%LOCALHOST% = %RECIPHOST%
%REMOTEHOST% = %SENDERHOST%
Outbound Mail
%LOCALHOST% = %SENDERHOST%
%REMOTEHOST% = %RECIPHOST%
Best Regards
Andy Schmidt
Phone: +1 201 934-3414 x20 (Business)
Fax:+1 201 934-9206
---
[This E-mail was scanned for viruse
> >> If you replied, Declude on your server would have "declude.com" for
>%REMOTEHOST%, but "HM-Software.com" for %SENDERHOST%. <<
>
>Let me see if I finally get it:
>
>Okay - I'm really only concerned about inbound mail.
Good -- the Return-Path: header should only be added to incoming E-mail.
>> If you replied, Declude on your server would have "declude.com" for
%REMOTEHOST%, but "HM-Software.com" for %SENDERHOST%. <<
Let me see if I finally get it:
Okay - I'm really only concerned about inbound mail. So - for INBOUND
messages, is REMOTEHOST and SENDERHOST always identical - if not,
>- The final SMTP server will PRESERVE the ENVELOPE FROM to the
>- RETURN PATH header, so that any bounces AFTER completion of
>- the SMTP process still know where to send bounces to.
>
>As I read RFC2821 7.2, second paragraph, a mail system should NOT do
>exactly this.
RFC2821 7.2 second paragr
>- No. The Return-Path: header is supposed to include the exact
>- address that was used in the "MAIL FROM:" SMTP command
>This:
>
>"It is possible for the mailbox in the return path to be different
>from the actual sender's mailbox, for example, if error responses are
>to be delivered to a spe
>> "There is no inherent relationship between either "reverse" (from MAIL,
SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction
("envelope") and the addresses in the headers. Receiving systems SHOULD NOT
attempt to deduce such relationships and use them to alter the headers
- -Original Message-
- From: [EMAIL PROTECTED]
- [mailto:[EMAIL PROTECTED]] On Behalf Of Andy Schmidt
- Sent: Friday, February 15, 2002 18:52
- To: [EMAIL PROTECTED]
- Subject: RE: [Declude.JunkMail] Return-Path - proper use?
-
-
- >> Im curious how this would be achieved without settin
>> Im curious how this would be achieved without setting the return-path:
header previously:
"It is possible for the mailbox in the return path to be different
from the actual sender's mailbox, for example, if error responses are
to be delivered to a special error handling mailbox rather than to
- -Original Message-
- From: [EMAIL PROTECTED]
- [mailto:[EMAIL PROTECTED]] On Behalf Of R.
- Scott Perry
- Sent: Friday, February 15, 2002 18:40
- To: [EMAIL PROTECTED]
- Subject: RE: [Declude.JunkMail] Return-Path vs. X-Sender header?
-
- >It can very well be some other address than t
>According to the manual:
>
>%REMOTEHOST% Remote host name (the remote domain)
>%SENDERHOST% Host name of the sender
>
>Are they different?
Yes, they are different.
The %REMOTEHOST% is always the host that connected to the IMail
server. %SENDERHOST% is the host that the sender is using.
If I
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1123.html
>> If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse path in the envelope;
see Section 3.6 of RFC-821.
> >> Allthough I don't see how the last server should acquire the address for
>the return-path: <<
>
>Well - it seems to me as if the last server has responsibility to report
>back to the relaying server that it was contacted from?
The Return-Path: header *must* take the address from the "MAIL
This is in response to several of the E-mails:
>afaik is the Return-Path: header used to determine where to return the
>mail in case it bounces and other postmaster messages.
That is correct.
>It can very well be some other address than the address where it was
>sent from. Like the reply-to: he
I took the info from RFC2821, which probably overrules 1123;
http://rfc.net/rfc2821.html
Im curious how this would be achieved without setting the return-path:
header previously:
"It is possible for the mailbox in the return path to be different
from the actual sender's mailbox, for example, if
RFC 1123 (http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1123.html)
"IMPLEMENTATION: The MAIL FROM: information may be passed as a parameter or
in a Return-Path: line inserted at the beginning of the message."
>> Allthough I don't see how the last server should acquire the address for
the return-p
I was curious, so I looked it up:
"When the delivery SMTP server makes the "final delivery" of a
message, it inserts a return-path line at the beginning of the mail
data. This use of return-path is required; mail systems MUST support
it. The return-path line preserves the information in the fr
And as a note, the preferred headers to set by servers with the envelope
to and from addresses are:
Apparently-To: & Apparently-From:
--
Regards,
Terrence Koeman
Technical Director/Administrator
MediaMonks B.V. (www.mediamonks.nl)
Please quote all replies in correspondence.
- -Original
Well, most servers do not handle Return-Path: correctly, but originally
it was intended to let the client decide where to get messages about the
mail they had sent. I don't think imail makes any use of the
Return-Path: header.
I think it'd be bad practice to set the Return-Path: header when
recei
>> afaik is the Return-Path: header used to determine where to return the
mail in case it bounces and other postmaster messages. It can very well be
some other address than the address where it was
sent from. Like the reply-to: header. <<
Uhhh - so this header should (and possibly could) have be
According to the manual:
%REMOTEHOST% Remote host name (the remote domain)
%SENDERHOST% Host name of the sender
Are they different? From where does Declude derive one value vs. the other?
One from the SMTP connect to Imail? The other from the very first "received
from" header?
Best Regards
An
afaik is the Return-Path: header used to determine where to return the
mail in case it bounces and other postmaster messages.
It can very well be some other address than the address where it was
sent from. Like the reply-to: header.
--
Regards,
Terrence Koeman
Technical Director/Administrator
> >> FYI, People running Declude JunkMail can add the following to their
>config files to fix this:
> XINHEADER Return-Path: < % MAILFROM % > <<
>
>You posted this in the Imail list.
>
>However, isn't that redundant with:
>
> >> If you want to record the name of the sender (accordi
>> FYI, People running Declude JunkMail can add the following to their
config files to fix this:
XINHEADER Return-Path: < % MAILFROM % > <<
You posted this in the Imail list.
However, isn't that redundant with:
>> If you want to record the name of the sender (according to the SMT
>What we would need is a Reverse DNS custom blacklist. Here is s typical SPAM
>header:
>
>Received: from s0260.pm0.net [199.236.13.43]
>
>If I could add "pm0.net" and "hispeedmailer.com" and others to a new
>"Reverse DNS" blacklist, then we wouldn't have to try to enter their
>complete IP block o
Hi,
I've come to realize, that the IP custom blacklist would too many individual
entries and the sender blacklist is usually faked (although it can be
helpful to add a weight factor for those free email services, like
Yahoo.com).
What we would need is a Reverse DNS custom blacklist. Here is s
>Yes, I have text after the domain. Here is what's in my blacklist file.
>
>networkpromotion.com270NetCustomBlacklist
>azoogle.com 270NetCustomBlacklist
>inyouremail.com 270netCustomBlacklist
>ientrymail.com 270netCustomBlacklist
>tm04.com
28 matches
Mail list logo
