At 08:32 2005-08-18 -0600, Lloyd Standish wrote:
I have a question about email redirection, as it relates to greylisting.
Is is true that email redirection is generally MTA-level, and that the
original sender IP is passed on by the redirecting computer to the
destination MTA? If this were not true, then greylisting would not work
for redirected mail, since the sender IP would be replaced by the IP of
the redirecting computer.
"Email redirecting"? Huh?
FORWARDING can either be performed at the MTA level (say, via an alias), or
at the local delivery level (.forward file contents or a procmail ! rule).
If performed at the local delivery level, the envelope sender becomes YOU,
the forwarder as it is being re-submitted to the MTA. If performed at the
MTA level, the original envelope sender is maintained (for one, there's no
actual "user" doing a forward). In either case, the message is fully
accepted from the sender by your MTA, and then a NEW message is queued up
for delivery by your MTA. When your MTA goes to connect to the remote
server to deliver the message, it's SMTP greeting is just like any other
message originating from your server - it's own IP and hostname.
I suspect you're confusing email operation with httpd features such as
server redirects, where the result message from the httpd can contain a new
location, which the client uses to ISSUE A NEW REQUEST. That's not how
email works.
Consider this: legitimate mail operations sometimes use "mail relays"
(sendmail calls them "smart" relays) - where the mail server relays the
message to a server outside of its own network, and that OTHER server
delivers it to its final destination. This can either be done on all mail,
except a few hosts manually configured otherwise (smart relaying with
exception hosts in the mailertable), or it can be done only on select
domains (normal delivery, with some hosts in the mailertable). I relay all
mail for a large website which happens to have an IP in a netblock (from
their provider) that appears in some provider-specific DNSBL (because their
webhosting provider at one point had hosted a spammer, which isn't these
guys, but their owner doesn't want to change hosting services). I also
relay mail destined for select domains (such as verizon/gte/etc) for an
auto enthusiast site hosted in Europe, because verizon is blocking mail
deliveries from certain IP ranges known to be associated with certain
countries (while they maintain that they're not) - by relaying the mail via
my servers, verizon sees the mail as coming to them from the USA. Relaying
isn't "forwarding" in the strict sense (the original recipient is still the
same recipient it'll be delivered to), but it's much the same process of
accepting a message and placing it in the send queue, then establishing an
outgoing connection to the MX for the recipient.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail